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 > >
