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

[Steve Ebersole]

I also think ORM 6 is not the time to do this.  Especially moving to Java
11.

I think it is worthwhile though to discuss possibly moving to Java 9 to
take advantage of multi-release jars as Christian mentioned.  But Java 9
has its own set of difficulties for adoption with modules.  It is a
tough call.


On Fri, Jul 24, 2020 at 10:09 AM Yoann Rodiere <yoann at hibernate.org> wrote:

> 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
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev