we don't have to "support" users on our main trunk branch. That's why we make releases.
On Thu, Nov 4, 2021 at 9:59 AM Michael Sokolov <msoko...@gmail.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
