[hibernate-dev] Dropping support for Java 8 in Hibernate ORM (Search) v6 ?

[Yoann Rodiere]

Hi,

I share Christian's concerns; Hibernate Search 6 is already a huge change
for users, so I'm not sure reducing our potential user base even further by
requiring JDK11 is a good idea.

I don't have numbers, but from my understanding a lot of people are still
on JDK8, be it only because of the whole modulepath mess that scared a lot
of people off (even though modules are optional...). If someone can prove
me wrong and show me reliable statistics about JDK8 users being a minority,
I'd be glad to put JDK8 behind me, but I doubt that's the case...

"Middleware" consumers of our libraries are another problem:

* Infinispan 12, from what I can see, still supports JDK 8.
* I believe Spring does, too.
* Quarkus, well... I suppose you know about Quarkus better than me.
* ...

Regarding benefits:

The only benefit I could see from moving to JDK11 is the availability of
the Flow interfaces, which would certainly be useful to introduce proper
Publisher/Subscriber support in Search queries. But then that's not
something we'll have time to work on anytime soon.

I may be mistaken, but I'm not sure Jigsaw is gaining enough traction to
justify investing more than just defining automatic modules for the time
being.

As to multi-tenancy in JDBC... Let's finish ORM6 first? :) Nothing stops us
from only publishing a 6.1, and then moving immediately to 7, if we really
end up addressing all the higher-priority items faster than expected and we
need JDK11 features soon.

Bottom line: maybe we could just deprecate JDK8? Log a warning on startup?
And yes, ORM7/Search7 may be a better time to move to JDK11.

On a side note, I'm not as enthusiastic as Christian about Moditect; last
time we tried to use it on Search, it required us to build with JDK11, so
we couldn't use it, since we were building releases with JDK8. Though
nowadays we build releases with JDK11 (and -release 8), so it may be an
option.


Yoann Rodière
Hibernate Team
yoann at hibernate.org


On Fri, 24 Jul 2020 at 16:23, Christian Beikov <christian.beikov at gmail.com>
wrote:

> Hey,
>
> 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
> requirement.
>
> 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?
>
> Regards,
>
> Christian
>
> Am 24.07.2020 um 16:00 schrieb Sanne Grinovero:
> > Hi all,
> >
> > [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
> > developed projects.
> >
> > 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?
> >
> > Any thoughts?
> >
> > Thanks,
> > Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>