I can understand the argument "people who want to be on older versions of Java can use older versions of Hibernate ORM/Search". However, this strategy will only benefit the projects if we *actually* stop working on much older versions... Experience taught me that's unlikely, and it's even more unlikely if we don't release a stable 6.0 (ORM and Search) very soon, but I guess we can try. So... okay.
The fact remains that major integrators of our libraries are still on Java 8, and will be for the foreseeable future: - Spring still supports Java 8, and I very much doubt they will drop such support anytime soon. - Quarkus still supports Java 8, but I understand you plan to remove that support soon (end of year, maybe?) - Wildfly is probably not a problem right now, due to the strict backward compatibility requirements that rule out an upgrade to 6.0 anyway. - Infinispan is only now starting to talk about moving their build to Java 11 [1] (no idea if they intend to remove runtime support for Java 8, since that's a separate issue). But they're only talking about the server part, and even if they solve that, there's still Infinispan Embedded. - I may be forgetting someone? For Quarkus/Spring, well... I suppose it comes down to what we discussed above about users. With what you're proposing, if a framework supports Java 8, they will not be able to upgrade at all. If we're talking about one year, that's manageable. If we're talking about leaving a whole framework worth of users on an older version of ORM/Search for ten years, that's terrible. The reality will be somewhere in the middle, and *I* certainly don't know where. For Infinispan, it's very much a blocking problem, since they are already on Hibernate Search 6 and can't really pick a different version of our library depending on the version of the Java runtime. We should probably solve that before we take any decision, at least for Search. [1] https://infinispan.zulipchat.com/#narrow/stream/118645-infinispan/topic/JDK.2011 Yoann Rodière Hibernate Team yo...@hibernate.org On Wed, 5 Aug 2020 at 18:02, Sanne Grinovero <sa...@hibernate.org> wrote: > 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 <st...@hibernate.org> 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 <yo...@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 > > > yo...@hibernate.org > > > > > > > > > On Fri, 24 Jul 2020 at 16:23, Christian Beikov < > christian.bei...@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@lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > _______________________________________________ > > > > hibernate-dev mailing list > > > > hibernate-dev@lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > > > > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev@lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
