I can imagine some users might like to keep abreast of main, at least in some kind of testing setup, but aren't ready to cut over their JDK for some reason (as Dawid was describing), but they can always do a small patch and build Lucene themselves, applying the -target for compatibility with their environments. And if we ever get to the point of really *requiring* compilation for the latest JDK, then it will probably be for a good reason, and we should prepare users for that.
On Thu, Nov 4, 2021 at 7:54 AM Robert Muir <rcm...@gmail.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
