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 <mailto:rcm...@gmail.com> > wrote: On Wed, Nov 3, 2021 at 1:36 PM Dawid Weiss <dawid.we...@gmail.com <mailto: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 <mailto:dev-unsubscr...@lucene.apache.org> For additional commands, e-mail: dev-h...@lucene.apache.org <mailto:dev-h...@lucene.apache.org>
