JDK 16 is now in Rampdown Phase Two
by Rory O'Donnell
Hi Sanne & Yoann,
*Per the JDK 16 schedule , we are in Rampdown Phase Two* *[1] .
*
*Please advise if you find any issues while testing the latest Early
Access builds.*
* Schedule for JDK 16
o *2021/01/14 Rampdown Phase Two*
o 2021/02/04 Initial Release Candidate
o 2021/02/18 Final Release Candidate
o 2021/03/16 General Availability
* Release Notes [2]
OpenJDK 16 Early Access build 32**is now available at
http://jdk.java.net/16
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Features [3] - the overall feature set is frozen. No further JEPs
will be targeted to this release.
* Changes in recent builds that maybe of interest:
o Build 32:
+ JDK-8259028 - ClassCastException when using custom
filesystem with wrapper FileChannel impl
# Apache Lucene found.
+ JDK-8253996 - Javac error on jdk16 build 18: invalid flag:
-Xdoclint:-missing
# Apache Zookeeper found.
o Build 31:
+ JDK-8259027: NullPointerException in makeMappedSegment due
to NULL Unmapper when length of segment is 0
# Reported by Apache Lucene
o Build 30:
+ JDK-8254023: A module declaration is not allowed to be a
target of an annotation that lacks an @Target meta-annotation
# Reported by JUnit5
+ JDK-8256693: getAnnotatedReceiverType parameterizes types
too eagerly
* JDK 16 - topics of interest
o Investigating MD5 overheads:
https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html
o Towards OpenJDK 17 - a quick update on startup performance
https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html
o Migrating OpenJDK to Git & GitHub - GitHub Universe 2020 session
replay
https://inside.java/2020/12/11/skara-github-universe/
Project Panama/foreign EA Build 16-panama+3-385 (2020/12/10)
<https://jdk.java.net/panama/> is available now [4]
* What's new
o jextract is now fully compatible with Java 16
o New architecture based on Foreign-Memory Access API (JEP 370
<https://openjdk.java.net/jeps/370>, JEP 383
<https://openjdk.java.net/jeps/383>, JEP 393
<https://openjdk.java.net/jeps/393>) and Foreign Linker API (JEP
389 <https://openjdk.java.net/jeps/389>)
* These early-access builds are provided under the GNU General Public
License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>
* EA builds are produced for the purpose of gathering feedback. Use
for any other purpose is at your own risk.
* Please send feedback via e-mail to panama-dev(a)openjdk.java.net
<panama-dev(a)openjdk.java.net>. To send e-mail to this address you
must first subscribe to the mailing list
<https://mail.openjdk.java.net/mailman/listinfo/panama-dev>.
* Project Panama - topics of interest
o “The Vector API” with John Rose and Paul Sandoz
https://inside.java/2020/11/17/podcast-007/
o “The Foreign Memory Access API” with Maurizio Cimadamore and
Jorn Vernee
https://inside.java/2020/12/11/podcast-009/
o “The Foreign Linker API” with Maurizio Cimadamore and Jorn Vernee
https://inside.java/2020/12/21/podcast-010/
OpenJDK 17 Early Access build 5**is now available at http://jdk.java.net/17
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Changes in recent builds that maybe of interest:
o Build 4:
+ JDK-8258800: Deprecate -XX:+AlwaysLockClassLoader
o Build 3:
+ JDK-8246005: KeyStoreSpi::engineStore(LoadStoreParameter)
spec mismatch to its behavior
+ JDK-8258765: getAnnotatedReceiverType parameterizes types
too eagerly
* JDK 17 - topic of interest
o Towards OpenJDK 17 - a quick update on startup performance:
+ https://cl4es.github.io/2020/12/06/Towards-OpenJDK-17.html
Java Cryptographic Roadmap [5] has been updated
* Removing root certificates with 1024-bit keys in July 2021 CPU.
* Disabling of SHA-1 JARS signed after 2019-01-01 has been postponed
to July 2021 CPU.
Rgds, Rory
[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2021-January/005001.html
[2] https://jdk.java.net/16/release-notes
[3] http://openjdk.java.net/projects/jdk/16/
<http://openjdk.java.net/projects/jdk/16/>
[4]
https://mail.openjdk.java.net/pipermail/panama-dev/2020-December/011605.html
<https://mail.openjdk.java.net/pipermail/panama-dev/2020-December/011605.html>
[5] https://java.com/en/jre-jdk-cryptoroadmap.html
<https://java.com/en/jre-jdk-cryptoroadmap.html>
16 hours, 34 minutes
FetchMode.SELECT
by Gail Badner
Should it be possible to force an eager association to be loaded by a
separate query using @Fetch(FetchMode.SELECT)?
I thought that Hibernate supported that for an EAGER association, but I see
the documentation for FetchMode.SELECT
<https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_...>
says:
"SELECT
The association is going to be fetched lazily using a secondary select for
each individual entity, collection, or join load. It’s equivalent to
JPA FetchType.LAZY fetching strategy."
The reason I ask is because I am trying to wrap up HHH-13085, which will
change derived IDs mapped as a one-to-one association, currently loaded by
a separate query, to instead be loaded in the same query that loads the
dependent entity. I want to ensure that it is possible to revert back to
loading that one-to-one association in a separate query after HHH-13085 is
fixed.
Currently, a StackOverflowError is thrown when loading an entity with an ID
that is an bidirectional eager one-to-one association has FetchMode.SELECT
mapped.
@Entity(name = "Foo")public class Foo implements Serializable {
@Id
@GeneratedValue
private Long id;
@OneToOne(mappedBy = "foo", cascade = CascadeType.ALL)
private Bar bar;
}
@Entity(name = "Bar")public class Bar implements Serializable {
@Id
@OneToOne(fetch = FetchType.EAGER)
@Fetch(FetchMode.SELECT)
@JoinColumn(name = "BAR_ID")
private Foo foo;
}
According to the documentation, it sounds like @Fetch(FetchMode.SELECT)
should make the association lazy. Is that really correct?
Could someone please clarify the expected behavior?
I created HHH-14390 <https://hibernate.atlassian.net/browse/HHH-14390> for
the StackOverflowError. I've pushed some FailureExpected tests
<https://github.com/hibernate/hibernate-orm/commit/b40d1251e385a5fdb018f95...>
that reproduce this issue.
Thanks,
Gail
5 days, 7 hours
