uschindler commented on PR #912: URL: https://github.com/apache/lucene/pull/912#issuecomment-1140527102
Hi Dawid, Thanks for feedback. Indeed the Tool chain API is very limited and in my honest opinion far from useful for Lucenes usages. There's no way to configure anything inside the Gradle files. Things like Autodownload or provider urls or locations of preinstalled jdks like on Jenkins cannot be put into the build files. It is also not possible to tell the system to download EA releases. It is all a desaster. I will tomorrow start a Twitter thread about this. The tool chain API should be flexible and allow plugins to configure own repository types. In general the tool chains should be standard configurations and dependencies in Gradle. The wax how it is now is a dead end: inflexible, buggy and looks like written by a student as bachelor thesis in isolation. I would wifmsh you change a configuration "toolkit" like any other and add the dependency to the java version there. Compile tasks would then use it automatically. Plugins can implement repositories in same way like Maven or ivy. EMG. One plugin for adoptopenjdk/ eclipse and another one for EA releases. About your comments: o wanted to keep the tool chain JVM hacks at one place because they currently only affect Lucene Core. Once we have a release of Java 19 we can simplify that (see code commented out). Other tasks than javac and jar are not affected. Javadics are not built and ecj/forbiddenapis/errorprone do not work at all, so I disabled them. It is just 2 classes to compile which are package private. If we get more MR-JAR stuff we may think of better ways. The current approach is a separate "singleton- in whole build. Maybe you can make it generic, but the combination with EA releases makes this impossible at moment. On top of that, preview APIs are another big problem. The Class files generated have a special minor version in class file format marking them as preview. This makes class loader picky. The code here won't run with Java 20, we will need a separate MR-JAR section for 20 and then for final release of panama in LTS 21 with unmarked class files. If the APIs will not change we may simplify this by removing the minor class version by patching class file version and only have the java 19 class files. You may read more about preview APIs in the jep, it's a mess to maintain: https://openjdk.java.net/jeps/12 At moment I also tried this PR with Luke: - if you start Luke with Java 17 all works as before, it won't see new classes and loads the byte buffer impl - if you start with Java 19 it will find the new classes, but class loader will reject to load them. Lucene will print a warning (you see it in Luke's log window and console). It will use byte buffer impl then - if you start Luke with Java 19 and `--enable-preview`, it will use new impl. So this is still opt in, which is good with preview APIs. - if you start with a possible Java 20, with or without preview enabled, it will reject the class files and falls back to our old byte buffer impl. In that case it logs warning to update Lucene. 😉 So this looks like working good and people can optionally test new mmap with Java 19 if they opt in (Solr or Elasticsearch). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
