Require Java 11 for Hibernate ORM 6.0

[Sanne]

Proposal for Hibernate ORM 6.0 to require Java 11 as minimal runtime JVM.

Let's try to enumerate our requirements, possible benefits and tradeoffs.

Who is Hibernate ORM 6 for?

Our requirements are essentially dictated by our users, and having many I have no doubt that dropping Java 8 compatibility will let down someone; but we need to also consider the benefits on the project, not least the opportunity costs of letting go older platforms for the benefit of freeing up our time on more valuable tasks.

I would also point out that surveying all our users will not provide us with useful data, as most of them are likely maintaining an existing system, and any mature system is likely to not upgrade to Hibernate ORM 6 yet - as this proposal has no impact on existing stable versions of Hibernate ORM 5, which will still aim to be compatible with Java 8 runtimes, and this proposal also has no impact on maintenance plans.

Users who do maintain projects actively and are following up on important updates such as Hibernate ORM 6 are likely to also have already upgraded JDK, as in most cases upgrading the runtime is a worthwhile task with an high benefit ratio and low risk.

The other aspect of our "requirements" is to satisfy the requirements of popular platforms integrating Hibernate:

Target platforms

It seems the most relevant platforms consuming Hibernate ORM are not planning to be compatible with Java 8.

Spring 6

As announced recently: Spring 6 is expected to require Java 17 . There is no expectation for older versions of Spring to support Hibernate ORM 6+, these will most likely keep using Hibernate ORM 5.x.

Quarkus

Quarkus is already requiring Java 11 today.

WildFly

WildFly is also planning to drop compability with Java 8 soon.

Other platforms

I'd say it is reasonable to consider all other platforms integrating Hibernate ORM to be in a similar position of all our individual users: if they are risk averse and still not upgrading from older JDKs, they are welcome to keep using Hibernate ORM v5 for longer.

Advantages

It would seem that the immediate advantages for us are not very compelling, still there are some good points to upgrade and I'd invite you to read the list not as individually persuasive points, but to consider that each area is otherwise a small pain point - and having many small pain points will be a problem in the long run. Especially worthwhile to consider the downsides for not upgrading are really low.

• more efficient representations of internal collections
• if we will want to support Java Modules in the near future, doing so is much less complicated when building on a compatible JVM
• less CI jobs to run
• more efficient bytecode being generated
• it's better to be clear about the requirements when releasing 6.0 rather than regretting not having taken the opportunity when some of these reasons will resonate more: we should avoid changing required JDK in a minor.

In particular while support of Java Modules is not currently on our roadmap, I expect it will be soon - it's quite complicated to do if we have to maintain Java 8 compatibility.

Drawbacks

• A minority of users will need to keep using Hibernate ORM 5. As mentioned I think this is acceptable.
• JDBC spec changes

As some mentioned, many JDBC driver vendors are still not implementing correctly the latest JDBC spec. Our requirement doesn't have impact on the bytecode of JDBC drivers though, so let's focus on how the JDBC API changes affect our own code and let's give an incentive to JDBC maintainers to catch up.

What this proposal is not

While it's tempting to discuss also if we should target an even more modern version, such as Java 17 which is also LTS and now available, I would suggest to focus on dropping compatiblity with Java 8 first.

Also I believe that dropping Java 11 compatibility is too aggressive at this point (and in conflict with the requirement to target Quarkus among compatible plaftorms), but we can certainly have a separate discussion about that.

Messaging & strategy

This is a bit more subtle, but it's also desireable to let users realize that Hibernate ORM 6 is a better fit for new(er) applications, as it's not meant as a drop-in replacement for applications running version 5.

Considering that we are a relatively small team, it is not in our interest to try having 100% of our active user base eligible to migrate to 6 as soon as it is released.

It is also reasonable to expect that while some minority of users will not be ble to upgrade to Java 11 yet, they will have to upgrade sometime in the near future (unless they are totally not maintaining their application, case in which they will not be upgrading Hibernate either).

Finally - the chicken and egg problem of our users still running on Java 8:

Some of our users have no direct control of which JDK they are running. But if we give them good reason - such as "this feature requires JDK 11 minimum" - then they will have a business justification to actually dedicate some time to address the JDK upgrade requirements.

Let's help people to make a case to upgrade.

[sebersole]

I agree with everything said here.

I would quibble a bit about JDBC however. Sure this is a problem with the driver vendors, but it impacts us via our users. While we can certainly make arguments for everything else mentioned here, if users cannot use 6.0 with their database, that is a much harder sell.

[Sanne]

I'm probably missing something here, please help me understand making this point more concrete.

Assuming an example end user "Jane" is planning to run her application running on OpenJDK11; would it help her in any way if Hibernate ORM had been compiled with JDK 8?

Or this this concern actually more like "No application using the JDBC driver from bad vendor X will ever work when running on OpenJDK > 8" ? Because in this second case I'd say too bad: either stay on older ORM, or get away from that terrible vendor.

[sebersole]

A natural follow-on to basing ORM on Java 11 is to start looking at JDBC 4.3 features. But as soon as we do that, Jane needs to use a JDBC 4.3 (Java 11) compliant driver.

So if the argument here is to move to Java 11 but not use any Java 11 features, then ok...

[Sanne]

Thanks yes that helps me understand it.

Ok so my proposal is to make the Hibernate ORM 6.0 release communicating clearly that Java 8 is not supported; this doesn't imply that we necessarily take advantage of any of it right away, it's only about making sure we have the flexibility to do so later.

And of course we can then agree if and when it's appropriate to also adopt JDBC 4.3 features, but this could be a topic for some follow-up minor release. I suppose we'll then be able to even choose different strategies per vendor, or other such smart things... but we can cross that bridge later.

On the other hand if we don't drop Java 8 compatibility, it would be harder to eventually take advantage of any JDBC 4.3 feature ... so this quibble seems to be a point in favour?

[sebersole]

Sure. I was not arguing against moving to 11. Just pointing out that...

As some mentioned, many JDBC driver vendors are still not implementing correctly the latest JDBC spec

Some don't even properly support JDBC 4.2 yet, let alone 4.3. If we stick to Java 8 for source compatibility for the short term, then great.

[Sanne]

It's settled then, closing the topic. Thanks all!

[Sanne]

Tracked as https://hibernate.atlassian.net/browse/HHH-14946