New CI machine preview
by Sanne Grinovero
You're all welcome to play with http://54.225.162.168/
however please keep these in mind:
- it's not the final machine: don't put too much effort in creating
nice build scripts as we'll reset it to clean state soon. We *might*
be able to store jobs defined so far, but we might choose not to.
- domain name should be coming: ci.hibernate.org ..not sure when, got
no replies so far from.
- authentication: just click on login, it will use OAuth2 to request
your identity via your GitHub account. Permissions to create new jobs,
edit existing jobs, run a build manually depend on your github account
be part of the Hibernate organization (or not, in which case you have
read only status)
At this stage I'd like to get a feeling if the hardware is powerful
enough, and also we need to select which other plugins we want to use,
I'm looking especially to:
- static analysis reports
- pull requests integration
both are relatively undefined, we can of course start simple and
improve later.. just checking this fits basic needs now.
Sanne
2 weeks
Allowing to override PhysicalConnectionHandlingMode on SessionBuilder: Deprecate?
by Sanne Grinovero
Hi all,
apparently we expose a method
SessionBuilder#connectionHandlingMode(PhysicalConnectionHandlingMode mode);
Yoann noticed that while the method was exposed, we didn't actually
apply the property [1].
I'm wondering if it's wise to expose this; I can imagine that it might
be possible to craft some tricky scenario in which one strategy is
slightly better than another, but I can't think of one which wouldn't
be far-fetched.
On the other hand, some of the possible strategies are not valid
options at all, depending on the integration of TransactionManager and
connection pools; more generally I would expect one wants to pick the
optimal strategy (as allowed by such other integrations) and stick
with it consistently for the application.
I'd suggest we deprecate this method for removal (without
replacement), unless I'm missing something?
The existing HHH-14404 seems to point that this wasn't used much.
Thanks
1 - https://hibernate.atlassian.net/browse/HHH-14404
4 years, 9 months
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>
4 years, 9 months
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
4 years, 10 months
