With the current release frequency, JDK 11 will be EOL by the time Lucene 10 is released.
Users can use lucene 9 if they want to stay on old outdated JDKs. On Thu, Nov 4, 2021 at 7:44 AM David Smiley <dsmi...@apache.org> wrote: > > I prefer that we require JDK 17 for build/test but allow our artifacts > (except lucene-test-framework maybe) to be run on JDK 11 (or 14?) via setting > the "target". This allows us some time to appreciate some of the benefits of > Java/JDK 17 without insisting that our users switch. This approach doesn't > prevent us from fully-committing to JDK 17 for Lucene 10 if we want. When we > consider that Lucene is a library and not a full app, we should be somewhat > conservative here. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Thu, Nov 4, 2021 at 6:10 AM Uwe Schindler <u...@thetaphi.de> wrote: >> >> Hi, >> >> >> >> I agree with this plan, lets go to JDK17 in Lucene 10 (main), but whenever a >> new Java version comes out, update Gradle and the –release=XX switch. Plain >> simple! The stable branch has a defined java version (currently “11”), >> “main” should be always latest. I don’t think this is a problem, because the >> Java release cycles have changed and people who are old-syled are still on 8 >> (so would be stuck with Lucene 8). For some larger companies they stick with >> officially “Oracle supported LTS” versions, but those people won’t upgrade >> soo. Nowadays with Docker and Kubernetes, it is so easy to start Solr or >> Elasticsearch with any Java version (and you don’t care, you just take >> what’s shipped with your image), so beeing bleeding edge on main is >> perfectly fine. When we release a new major version, we take what’s latest >> at that time (based on main branch, hopefully with Panama). >> >> >> >> Based on my previous statement, JDK 17 is not the final goal for Lucene 10, >> and not even 18 it is: JDK 18 won’t contain Panama (they have a second >> icubator of Total-Panama), so it is likely to be part of “java.base” Module >> in JDK 19 (still requiring some extra enabler-command line param). >> >> >> >> About 17: What I like most is the multiline-Strings and the new switch >> statement. In addition to Robert’s comment: I like it not only because of >> the break-hell, more because it is not a simple statement, but an expression >> (having return value). So the anti-pattern like a variable and then a switch >> stament assigning a value to this variable in each case is then finally >> obsolete. You have then “variable = switch(….)”. And finally we will get a >> switch for instanceofs a bit later (hopefully at same time when Panama comes >> out) 😊 >> >> >> >> Records are bullshit, sorry. It’s only useful for the >> Hibernate/Spring/Foobar-like Entities-For-Everything business logic. It may >> be useful at some point when they are no instances on heap anymore and just >> data wrappers, but based on classes I see no reason to use them for Lucene. >> >> >> >> Uwe >> >> >> >> ----- >> >> Uwe Schindler >> >> Achterdiek 19, D-28357 Bremen >> >> https://www.thetaphi.de >> >> eMail: u...@thetaphi.de >> >> >> >> From: Dawid Weiss <dawid.we...@gmail.com> >> Sent: Thursday, November 4, 2021 8:27 AM >> To: Lucene Dev <dev@lucene.apache.org> >> Subject: Re: Bump minimum Java version to 17 on main (10.0) >> >> >> >> >> >> Now you're talking. >> >> +1. >> >> >> >> >> >> On Thu, Nov 4, 2021 at 1:49 AM Robert Muir <rcm...@gmail.com> wrote: >> >> On Wed, Nov 3, 2021 at 1:36 PM Dawid Weiss <dawid.we...@gmail.com> wrote: >> > >> > I principally agree with you - we should leverage new Java features and >> > I'm all for it. I just don't see much difference between >> > Java 11 and 17 in the context of Lucene... Upgrading for the sake of >> > upgrading doesn't justify the move to >> > me. But if you can point at a feature of Java 17 and say - here, this is >> > great and was not there before, it's worth using, then I'm all in. >> > >> > D. >> >> absolute-bulk-get methods on Byte/Short/Int/Long/Float/DoubleBuffers? >> >> I think we should investigate it for MMapDirectory and >> ByteBuffersDirectory at least? Maybe it can create new opportunities, >> e.g. reduce overhead vs position()+get(). Or maybe expand our >> random-access API to include it, and perhaps bit-unpacking can be >> simplified or sped up (e.g. DirectReader). Especially now that we have >> varhandles it seems to make more things possible. Or maybe there's no >> performance win for us and it only simplifies existing code in the >> short-term. >> >> I like the new PRNGs, maybe we should replace our handrolled >> xorshift128 stuff that is used for segment IDs (see StringHelper). The >> new API has nice set of algorithms: >> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/package-summary.html. >> Good to look at for the HNSW vector stuff, too. Maybe, we should >> switch over unit tests eventually too. >> >> The JFR runtime streaming api looks interesting, maybe we could >> improve tests.profile to use it, or mike's benchmark. >> I like that they fixed multicast api to work correctly (IIRC >> previously you had to implicitly bind to all interfaces, couldn't even >> bind to just localhost). Theoretically it could be more efficient for >> stuff like replication, but there's still practical issues (e.g. you >> have to deal with UDP, some cloud environments have spotty support, >> etc). >> Unix Sockets! Now they work with windows, so java exposed them. I use >> these heavily at work, curl --unix-socket is my GOTO. it's a nice >> bonus you can protect them with ordinary file permissions on Linux at >> least. I love apps like haproxy that expose stats/control interfaces >> first-class over unix sockets. Infostream logging is nice, but maybe >> we should provide other options to make it easy to get >> metrics/statistics counters and such "live". >> I like that the Unicode version is bumped, that helps the lucene >> analyzers based on the JDK. >> I'm also a fan of the HexFormat to replace any hand-rolled >> hex-printers. Could probably clean up some test code at least. >> >> There's a lot of little improvements to the API like this: >> https://docs.oracle.com/en/java/javase/17/docs/api/new-list.html >> >> As far as the language/major features, sure they are just sugar >> sometime, but often it makes sense to refactor the code to use them. >> E.G. having text block support, it is just one of those little things >> that can make the code much easier. And I get spoiled by other >> languages that all seem to have this. >> There's a new packaging tool that might be appropriate for Luke, not sure. >> Maybe lucene/expressions should use Hidden Classes? I can't remember >> the details, but I think we make a private child classloader, register >> the class there, to try to prevent GC hell. But why register it at >> all? >> The switch expressions looks interesting, because we could remove some >> of the horrors of forgotten-break statements and stuff? Haven't looked >> in detail, I think we are doing stuff with ecj to try to detect these >> mistakes already. Seems potentially less error-prone to use the new >> syntax. >> >> You can easily see the full list of these language/major features since java >> 11: >> https://openjdk.java.net/projects/jdk/12/ >> https://openjdk.java.net/projects/jdk/13/ >> https://openjdk.java.net/projects/jdk/14/ >> https://openjdk.java.net/projects/jdk/15/ >> https://openjdk.java.net/projects/jdk/16/ >> https://openjdk.java.net/projects/jdk/17/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
