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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)hibernate.org On Fri, 24 Jul 2020 at 16:23, Christian Beikov <christian.beikov(a)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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Sure, we can wait to drop Java 8 if you all feel strongly about it, but give my proposal a chance :) Let me address a couple random points: Java version 9 and 10 are not useful versions to support: only 8 and 11 have long term support, so 9 and 10 are already out of support. All surveys I've seen show that 9 and 10 have been largely ignored by production users and enterprise professionals: they either use 8 or 11, or occasionally people the very latest. So if there's any interest in taking advantage from any benefit which came in 9 onward (such as multi-release jars as mentioned by Steve), you might as well skip to 11. Specifically, multi-release jars have loads of tooling issues still, both for us and our end users (e.g. the IDE to show source code), and a big problem to support as people might end up using mismatched versions of the code. As I mentioned there are no extremely compelling reasons to jump to 11, but it does simplify some things, which - when used pervasively - simplify our own code and maintenance while introducing small runtime benefits as well, such as consuming slightly less memory with the improvements to collections and streams. Regarding users, I'm simply fine with letting people use our 5.x series for as long as they wish. You should all keep in mind that we have a very high number of users, and with a small team it's just not smart from our part to have them all try to jump on our latest: we risk getting drowned in feedback, it's better to be selective with our users and "pick" the ones which are more innovative. The ones still requiring Java 8 will eventually upgrade as well, I'm just not worried that we need to encourage them to upgrade right away. Last but not least, even if supporting Java 8 comes relatively easy for us, it's an additional burden and it's one we could avoid. Certainly easier to drop it than starting to waste our time on obscure issues caused by multi-release jars and such tools, or having to maintain compatibility including at dependency tree (xml-bind apis, and all those modules being different). It's an opportunity to simplify, I'd take it. For users, it's more important to set clear expectations and communicate this early. Thanks, Sanne On Fri, 24 Jul 2020 at 17:35, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > 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(a)hibernate.org&gt; 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(a)hibernate.org > > > > > > On Fri, 24 Jul 2020 at 16:23, Christian Beikov < christian.beikov(a)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(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev