It is crazy classfiles are involved here at all. It is even crazier to be reading classfiles of the JDK itself. I just asked to print the help... crazy groovy
On Wed, Jan 8, 2020 at 12:27 PM Uwe Schindler <[email protected]> wrote: > Hi, > > Sorry, this is a no-go for going to gradle. We currently want to build and > test Lucene with all newer Java versions, including EA releases. I have no > idea why the Gradle people are not looking into the issue of > forward-compatibility. > > I had a long discussion already on the OpenJDK mailing lists about the > classfile version issue. The problem is mainly ASM that's used for bytecode > analysis where Gradle and Groovy depend on. If you pass ASM a classfile > version that it does not unerstand it brings this error. > > I had a discussion with Remi Forax. My proposal would be: > ClassReader should have 2 modes: > - strict mode that enables all features (like you can add filtering on top > of like method renames,.... and so pass the ClassReader (as visitor) to a > ClassWriter. This strict mode ensures that a ClassReader then passed to > ClassWriter produces the same class file. The requires that ASM fully > understands the class file. > - lenient mode: This marks the classreader/visitor as "risky". When > passing this to ClassReader, it can open any class file, also those with > newer class file versions. The classfile format is made in a way > (attributes) that you can easily read over features you don't understand. > In that case you can use a ClassReader like this to read method signatures, > run forbiddenapi checks,... (what MOST code out there using ASM is doing!). > The special flag on the visitor interface is then there to protect people. > If you pass a "lenient" class reader to a ClassWriter, the ClassWriter > complains. So you cannot open a ClassReader in lenient way and pass it to > ClassWriter, because that would produce a classfile where maybe a > significant part of stuff is missing/incorrect. > > In short: If there would be a non-picky ASM version / ASM mode like > proposed before - that can just be used for "analysis" of class files, > Gradle would be forward compatible. But Remi is too academic and also does > not want this because he sees some "maintenance" trouble. But this is why I > said strict mode and lenient mode. In lenient mode you cannot complain if > your code behaves wrong when you open a class file that is newer than the > version of ASM supports. > > In forbiddenapis I use hack to provide this leniency: When opening class > files, I just patch the version number. Maybe gradle should do the same - > IF AND ONLY IF IT DOES NOT USE IT FOR WRITING DERIVATIVE CLASS FILES: > > Maybe we could try to confive Gradle, Groovy and maybe Remi to take one of > those routes. Otherwise we cannot use Gradle with CI builds. > > An alternative here is to go the Elasticsearch approach: Gradle and the > Build runs with Java 11 and the Tests are running optionally with a later > version - by pasisng a system property pointing to a TestRunner JDK. > > Uwe > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: [email protected] > > > -----Original Message----- > > From: Dawid Weiss <[email protected]> > > Sent: Wednesday, January 8, 2020 6:06 PM > > To: Lucene Dev <[email protected]> > > Subject: Re: Gradle build to land on master > > > > > right, that file is the exact one i change. the problem is if i change > it to 6.0.1, > > then it wants me to buy something. > > > > You can't change to any other gradle version -- stick to the version > > defined in the wrapper and java 11. It is a fragile environment - > > switching gradle version will cause plugin incompatibilities, etc. > > Sigh. > > > > We can't upgrade to gradle 6.x yet because palantir's plugin for > > dependency management doesn't work for me then. > > > > Different JVM configurations may be rough, especially with newer JVMs. > > > > D. > > > > > > > On Wed, Jan 8, 2020 at 10:08 AM Thomas Matthijs <[email protected]> > wrote: > > >> > > >> ./gradlew should try to use gradle 5.6.4 see > > >> ./gradle/wrapper/gradle-wrapper.properties > > >> With java 11 this all builds fine for me (can export JAVA_HOME to > change) > > >> Which version of java are you using? the linked issue hints at java > 13? > > >> > > >> On Wed, 8 Jan 2020 at 16:01, Robert Muir <[email protected]> wrote: > > >> > > > >> > Here is the issue: https://github.com/gradle/gradle/issues/8681 > > >> > > > >> > I tried upgrading gradle to 6.0.1, but it seems now it wants me to > buy > > something? > > >> > > > >> > ]$ ./gradlew help > > >> > Starting a Gradle Daemon (subsequent builds will be faster) > > >> > > > >> > FAILURE: Build failed with an exception. > > >> > > > >> > * Where: > > >> > Build file > '/Users/rob.muir/eclipse.workspace/lucene-solr/build.gradle' line: > > 5 > > >> > > > >> > * What went wrong: > > >> > An exception occurred applying plugin request [id: > 'com.gradle.build-scan', > > version: '3.0'] > > >> > > Failed to apply plugin [id 'com.gradle.build-scan'] > > >> > > This build scan plugin is not compatible with less than Gradle > 6.0. > > >> > Please use the Gradle Enterprise plugin instead. > > >> > > > >> > On Wed, Jan 8, 2020 at 9:41 AM Robert Muir <[email protected]> > wrote: > > >> >> > > >> >> I tried it out just to see, here was my experience: > > >> >> > > >> >> $ git checkout gradle-master > > >> >> Switched to branch 'gradle-master' > > >> >> Your branch is up to date with 'origin/gradle-master'. > > >> >> $ ./gradlew help > > >> >> Starting a Gradle Daemon (subsequent builds will be faster) > > >> >> > > >> >> FAILURE: Build failed with an exception. > > >> >> > > >> >> * Where: > > >> >> Settings file '/Users/rob.muir/eclipse.workspace/lucene- > > solr/settings.gradle' > > >> >> > > >> >> * What went wrong: > > >> >> Could not compile settings file > > '/Users/rob.muir/eclipse.workspace/lucene-solr/settings.gradle'. > > >> >> > startup failed: > > >> >> General error during semantic analysis: Unsupported class file > major > > version 57 > > >> >> > > >> >> java.lang.IllegalArgumentException: Unsupported class file major > > version 57 > > >> >> at > groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:184) > > >> >> at > groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:166) > > >> >> at > groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:152) > > >> >> at > groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:273) > > >> >> at > > org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompile > > r.java:81) > > >> >> at > > org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeRes > > olver.java:254) > > >> >> at > > > org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(Class > > NodeResolver.java:192) > > >> >> > > >> >> On Wed, Jan 8, 2020 at 9:30 AM Dawid Weiss <[email protected]> > > wrote: > > >> >>> > > >> >>> I think the gradle-master branch is already workable enough to > land on > > master. > > >> >>> > > >> >>> If you're not familiar with gradle then, once merged, run > "gradlew help". > > >> >>> > > >> >>> Some notes. > > >> >>> > > >> >>> 1) I have been running tests on Windows and Linux, they're ok. The > > >> >>> output is slightly different from ANT's but I think it's fine for > > >> >>> working. > > >> >>> > > >> >>> 2) The speed of compilation and running tests selectively is much > > >> >>> better than ant's, especially on multicore machines. > > >> >>> > > >> >>> 3) I use IntelliJ idea and the project imports into the IDE > without > > >> >>> any special handling. Code formatting and such may need to be > adjusted > > >> >>> though. > > >> >>> > > >> >>> 4) Some things are incomplete (precommit does a subset of checks). > > >> >>> Some are missing (regeneration tasks). Some are different > (handling of > > >> >>> dependencies, build output folder locations). It will take some > time > > >> >>> and learning to live with a new build system. I tried to provide > short > > >> >>> guides into selective areas (they're available as help tasks or > plain > > >> >>> text files under help/). > > >> >>> > > >> >>> 5) If something does *not* work, let me know. > > >> >>> > > >> >>> 6) It'd be nice if we had a build job somewhere on a faster > machine > > >> >>> that would run at least "gradlew precommit check -x test" so that > > >> >>> rudimentary checks are applied, without running all the tests. > This > > >> >>> would ensure consistency in dependencies, for example. > > >> >>> > > >> >>> 7) The parallel branch (gradle-master) and issue (LUCENE-9077) > will be > > >> >>> kept open and occasionally merged back and forth. > > >> >>> > > >> >>> I have to shift more focus to my daily job but will help out and > chip > > >> >>> at the remaining bits, time permitting. > > >> >>> > > >> >>> Dawid > > >> >>> > > >> >>> > --------------------------------------------------------------------- > > >> >>> To unsubscribe, e-mail: [email protected] > > >> >>> For additional commands, e-mail: [email protected] > > >> >>> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
