Hi, > 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.
I think you misunderstood what I said: We still have a stable branch where we backport our stuff to. So the main branch is really for "trying out and working on new stuff". That's what a main branch is thought for. And if you read my original mail, that's what I am behind. We should focus on latest JDK with our main branch and try to optimize our APIs to use that, otherwise we will stay in a loop of ever supporting old bullshit forever. If a change in the main branch is so exhaustive that we think: "oh this will annoy users", then it is the point to create a new stable branch before and release it as new major version, before the crazy stuff gets in. At this point, we provide users with some brand new version that works with the brand new JDK. What's wrong with that? And before that we have the stable branch like we always did. If we can backport stuff we should do it. It may involve some nuking of JDK features we can't use in the stable branch, but this will bring pressure to the users: if you want newest features, upgrade your JDK. If you can't your stuck with old Lucene. But this is what our users are like: The conservative ones are also conservative with JDK versions. The hipster ones have hipster kubernetes clusters and don't care about the JDK version. They just install their app that fits their needs and the JDK is bundled. We're far ahead Java 5 where people were complaining about generics (says the generics policeman) and everybody had their JBoss Tomcat running Slowlar inside with JDK 1.4. Uwe > 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/rando > m/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
