I'm not sure it is a good idea to do this for Hibernate ORM 6 already as
that would probably hinder adoption. Some projects just didn't update to
Java 9+ yet because using the newer versions would have no real benefit.
We can use the Multi-Release JAR feature to make use of JDK features
introduced in newer Java versions. Since the Java 11 doesn't provide any
significant languages changes for which it would be worth dropping
support for Java 8, I see no reason for raising the minimum version
We can benefit from Jigsaw already by defining module-info file and let
the moditect plugin(from Gunnar) compile it. If necessary, we can make
use of the Multi-Release JAR feature to use the module system APIs.
How about raising the minimum Java version for Hibernate ORM 7 instead?
Am 24.07.2020 um 16:00 schrieb Sanne Grinovero:
[meta: I had this email as a draft on hold since a year; very glad to
finally be able to send it.]
We're usually quite conservative in dropping support for older JDKs
within the Hibernate team, but there's an increasing maintenance (and
development) cost when keeping older JDK compatibility for too long.
In particular, Java 8 compatibility was so far still a requirement for
various strategic integrations; first, we had runtimes targeting
GraalVM still needing it, but they support Java 11 now as well; after
that, Azure Functions were also still requiring Java 8, but this
limitation was resolved now.
We're aware that Java 8 is still widely used; still I think we need to
look forward - for various reasons, including maintenance burden, and
to deliver a better experience on the later versions of the JDK. Also,
looking at the existing usage statistics implies a fallacy: that's
current production usage, while the code we normally work is
(typically) not going to see production usage for quite some time.
While we'll want to keep Java 8 compatibility for existing
[maintained] releases, there is no compelling reason anymore to keep
doing this for the upcoming major releases.
So I'd propose we require Java 11 the minimum compatible runtime for
ORM v6 onward, and I'd suggest we do the same with all our actively
Initially, I don't really expect this to significantly increase the
efforts from our already packed roadmaps: in the first stage this
proposal is literally only about making minimal changes to our build
scripts to change the compatibility versions, and for CI to stop
testing the JDK/branches combinations which are no longer supported.
In a second step, as convenient, we'll be able to:
- do some code cleanup / refactorings to benefit from the minor API
improvements of the JDK
- some APIs had more substantial improvements, such as java.sql now
features native support for multi-tenancy, literals and identifiers
enquoting [among others] .. might be interesting.
- finally benefit from Jigsaw?
hibernate-dev mailing list