Building Gant

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Building Gant

Russel Winder-3
I know no-one (including me) really gives a #### about Gant these days
– except perhaps Bob Swift for GINT – but it is useful for testing
Gradle and Groovy.

Currently I build against:

3.0.0 using my build from master/HEAD
2.4.x
2.5.x
2.6.x

where I use the latest version of 2.4, 2.5, and 2.6.

3.0.0-SNAPSHOT, 2.4.15, and 2.5.0-rc-1 all build and tests execute and
fail in not unreasonable ways. 2.6.0-alpha-3 fails due to something the
creates the following stack trace. I am running OpenJDK10 obviously.
Should I just forget Groovy 2.6.0?


General error during conversion: java.lang.IllegalArgumentException

java.lang.IllegalArgumentException
        at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:160)
        at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:143)
        at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:418)
        at org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:83)
        at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
        at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)
        at org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:172)
        at org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:128)
        at org.codehaus.groovy.control.ResolveVisitor.resolveToOuter(ResolveVisitor.java:722)
        at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:359)
        at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1285)
        at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:213)
        at org.codehaus.groovy.tools.javac.JavaAwareCompilationUnit$1.call(JavaAwareCompilationUnit.java:76)
        at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1090)
        at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:634)
        at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:612)
        at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:589)
        at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:568)
        at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:175)
        at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:56)
        at org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:74)
        at org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:62)
        at org.gradle.api.internal.tasks.compile.daemon.AbstractDaemonCompiler$CompilerRunnable.run(AbstractDaemonCompiler.java:87)
        at org.gradle.workers.internal.DefaultWorkerServer.execute(DefaultWorkerServer.java:36)
        at org.gradle.workers.internal.WorkerDaemonServer.execute(WorkerDaemonServer.java:46)
        at org.gradle.workers.internal.WorkerDaemonServer.execute(WorkerDaemonServer.java:30)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.gradle.process.internal.worker.request.WorkerAction.run(WorkerAction.java:100)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:146)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:128)
        at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
        at java.base/java.lang.Thread.run(Thread.java:844)



--
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Building Gant

Jochen Theodorou
On 16.04.2018 19:16, Russel Winder wrote:

> I know no-one (including me) really gives a #### about Gant these days
> – except perhaps Bob Swift for GINT – but it is useful for testing
> Gradle and Groovy.
>
> Currently I build against:
>
> 3.0.0 using my build from master/HEAD
> 2.4.x
> 2.5.x
> 2.6.x
>
> where I use the latest version of 2.4, 2.5, and 2.6.
>
> 3.0.0-SNAPSHOT, 2.4.15, and 2.5.0-rc-1 all build and tests execute and
> fail in not unreasonable ways. 2.6.0-alpha-3 fails due to something the
> creates the following stack trace. I am running OpenJDK10 obviously.
> Should I just forget Groovy 2.6.0?
>
>
> General error during conversion: java.lang.IllegalArgumentException
>
> java.lang.IllegalArgumentException
>          at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:160)
>          at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:143)
>          at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:418)

judging by the few examples I found online this mandates ASM 6.1.1
(https://mvnrepository.com/artifact/org.ow2.asm/asm/6.1.1) 6.1 comes
with Java10 support. No idea what they added in 10, that is not binary
compatible. I was not following that so much

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Building Gant

Remi Forax
----- Mail original -----
> De: "Jochen Theodorou" <[hidden email]>
> À: "dev" <[hidden email]>, "Russel Winder" <[hidden email]>
> Envoyé: Lundi 16 Avril 2018 21:22:36
> Objet: Re: Building Gant

> On 16.04.2018 19:16, Russel Winder wrote:
>> I know no-one (including me) really gives a #### about Gant these days
>> – except perhaps Bob Swift for GINT – but it is useful for testing
>> Gradle and Groovy.
>>
>> Currently I build against:
>>
>> 3.0.0 using my build from master/HEAD
>> 2.4.x
>> 2.5.x
>> 2.6.x
>>
>> where I use the latest version of 2.4, 2.5, and 2.6.
>>
>> 3.0.0-SNAPSHOT, 2.4.15, and 2.5.0-rc-1 all build and tests execute and
>> fail in not unreasonable ways. 2.6.0-alpha-3 fails due to something the
>> creates the following stack trace. I am running OpenJDK10 obviously.
>> Should I just forget Groovy 2.6.0?
>>
>>
>> General error during conversion: java.lang.IllegalArgumentException
>>
>> java.lang.IllegalArgumentException
>>          at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:160)
>>          at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:143)
>>          at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:418)
>
> judging by the few examples I found online this mandates ASM 6.1.1
> (https://mvnrepository.com/artifact/org.ow2.asm/asm/6.1.1) 6.1 comes
> with Java10 support. No idea what they added in 10, that is not binary
> compatible. I was not following that so much

the support of version 54.0 and only one sentence in section 4.7.25, see https://bugs.openjdk.java.net/browse/JDK-8191867

>
> bye Jochen

Rémi
Reply | Threaded
Open this post in threaded view
|

Re: Building Gant

Jochen Theodorou
On 16.04.2018 21:38, Remi Forax wrote:
[...]
> the support of version 54.0 and only one sentence in section 4.7.25, see https://bugs.openjdk.java.net/browse/JDK-8191867

that is the only change in bytecode? There have been enough flags in the
bytecode the JVM just ignores, that could have been done here as well -
or do I overlook something important?

Anyway, thanks for the pointer, very appreciated.

ASM related question: if Java now releases so much more often and is
much more often changing the bytecode version, wouldn't it be an option
to optionally disable the bytecode version check? Even if that means to
fail strangely in another place? I don't think a java9 based class
reader would have had problems with this bytecode. Might be this is a
special case of course and might be the next 10 cases are too severe for
this, you know surely better than I do. Its just a thought

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Building Gant

paulk_asert
In reply to this post by Russel Winder-3
We just released 2.5.0-rc-1 and 3.0.0-alpha-2 (thanks Daniel). These should have ASM-6.1.1. I guess we need to release 2.4.16 and a fresh 2.6.0 alpha too so they are all on that release. I also want to do 2.5.0-rc-2 very soon. So I suspect you will be in better shape shortly.

Cheers, Paul.


On Tue, Apr 17, 2018 at 3:16 AM, Russel Winder <[hidden email]> wrote:
I know no-one (including me) really gives a #### about Gant these days
– except perhaps Bob Swift for GINT – but it is useful for testing
Gradle and Groovy.

Currently I build against:

3.0.0 using my build from master/HEAD
2.4.x
2.5.x
2.6.x

where I use the latest version of 2.4, 2.5, and 2.6.

3.0.0-SNAPSHOT, 2.4.15, and 2.5.0-rc-1 all build and tests execute and
fail in not unreasonable ways. 2.6.0-alpha-3 fails due to something the
creates the following stack trace. I am running OpenJDK10 obviously.
Should I just forget Groovy 2.6.0?


General error during conversion: java.lang.IllegalArgumentException

java.lang.IllegalArgumentException
        at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:160)
        at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:143)
        at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:418)
        at org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:83)
        at org.codehaus.groovy.control.ClassNodeResolver.findDecompiled(ClassNodeResolver.java:254)
        at org.codehaus.groovy.control.ClassNodeResolver.tryAsLoaderClassOrScript(ClassNodeResolver.java:192)
        at org.codehaus.groovy.control.ClassNodeResolver.findClassNode(ClassNodeResolver.java:172)
        at org.codehaus.groovy.control.ClassNodeResolver.resolveName(ClassNodeResolver.java:128)
        at org.codehaus.groovy.control.ResolveVisitor.resolveToOuter(ResolveVisitor.java:722)
        at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:359)
        at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1285)
        at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:213)
        at org.codehaus.groovy.tools.javac.JavaAwareCompilationUnit$1.call(JavaAwareCompilationUnit.java:76)
        at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1090)
        at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:634)
        at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:612)
        at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:589)
        at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:568)
        at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:175)
        at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:56)
        at org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:74)
        at org.gradle.api.internal.tasks.compile.GroovyCompilerFactory$DaemonSideCompiler.execute(GroovyCompilerFactory.java:62)
        at org.gradle.api.internal.tasks.compile.daemon.AbstractDaemonCompiler$CompilerRunnable.run(AbstractDaemonCompiler.java:87)
        at org.gradle.workers.internal.DefaultWorkerServer.execute(DefaultWorkerServer.java:36)
        at org.gradle.workers.internal.WorkerDaemonServer.execute(WorkerDaemonServer.java:46)
        at org.gradle.workers.internal.WorkerDaemonServer.execute(WorkerDaemonServer.java:30)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.gradle.process.internal.worker.request.WorkerAction.run(WorkerAction.java:100)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
        at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:146)
        at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:128)
        at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
        at java.base/java.lang.Thread.run(Thread.java:844)



--
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

Reply | Threaded
Open this post in threaded view
|

Re: Building Gant

Remi Forax
In reply to this post by Jochen Theodorou


----- Mail original -----
> De: "Jochen Theodorou" <[hidden email]>
> À: "Remi Forax" <[hidden email]>
> Cc: "dev" <[hidden email]>
> Envoyé: Lundi 16 Avril 2018 22:28:58
> Objet: Re: Building Gant

> On 16.04.2018 21:38, Remi Forax wrote:
> [...]
>> the support of version 54.0 and only one sentence in section 4.7.25, see
>> https://bugs.openjdk.java.net/browse/JDK-8191867
>
> that is the only change in bytecode? There have been enough flags in the
> bytecode the JVM just ignores, that could have been done here as well -
> or do I overlook something important?

Compatibility between VMs (Hotspot is not the only one).

Being able to say that a module requires java.base with ACC_STATIC_PHASE means that the module will compile with java.base but can run without it at runtime (no java.lang.Object, jikes !),
so if a VM really respect the JVMS 9, a user can create a module that works at compile time and fails at runtime, something the whole module system try to avoid.
For ACC_TRANSITIVE, it's less an issue, it means that java.base will be re-exported to the modules that requires the module, so those modules will have two java.base, it's just useless.

>
> Anyway, thanks for the pointer, very appreciated.
>
> ASM related question: if Java now releases so much more often and is
> much more often changing the bytecode version, wouldn't it be an option
> to optionally disable the bytecode version check?

No :)

> Even if that means to fail strangely in another place?

For this exact reason, historically we did not have this bytecode version check, and we spend a lot of time to track weird bugs that was just side effects of people using the wrong version.
The VM doesn't work if it's not the right version, it no different for ASM.

> I don't think a java9 based class  reader would have had problems with this bytecode. Might be this is a
> special case of course and might be the next 10 cases are too severe for this, you know surely better than I do. Its just a thought

You're right that java 10 was a minor version update in term of bytecode (mostly because the NestMate feature was moved to 11) but Java 11 is around the corner and a java 9 bytecode class reader will choke on Java 11 class, there is a new constant pool constant, the semantics of the minor version has changed and you have new attributes (NestMate) that change the security checks performs by the VM.

>
> bye Jochen

regards,
Rémi