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