New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix instrumentation to not violate Java Virtual Machine Specification regarding initialization of final fields #434

Merged
merged 1 commit into from Aug 16, 2016

Conversation

4 participants
@Godin
Member

Godin commented Jul 26, 2016

Currently FieldProbeArrayStrategy creates static final field $jacocoData, value for which is set by bytecode instruction putstatic in method $jacocoInit, but according to JVMS:

if the field is final the instruction must occur in the < clinit > method of the current class. Otherwise, an IllegalAccessError is thrown.

Starting with OpenJDK 9 EA b127 this condition is checked for class files with version >=53 - http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/c558d46c1af2#l11.76 Unfortunately we compile classes into 52 even with JDK 9, because maven-shade-plugin can't handle 53, and that's why we don't get failure in core validation tests, but later in integration tests for Ant on one of JDK classes:

Exception in thread "main" java.lang.IllegalAccessError: Update to static final field java.sql.Timestamp.$jacocoData attempted from a different method (java.sql.Timestamp) than the initializer method <clinit> 
    at java.sql.Timestamp.$jacocoInit(java.sql@9-ea/Timestamp.java)
    at java.sql.Timestamp.<clinit>(java.sql@9-ea/Timestamp.java)
    at org.jacoco.ant.TestTarget.main(TestTarget.java:36)

There is also a report in our mailing list - https://groups.google.com/d/msg/jacoco/jHw39ZUjUNY/L-gHeMeBBQAJ

See https://bugs.openjdk.java.net/browse/JDK-8157181 which is associated with this check and which also states:

Methods that do not satisfy condition violate the assumptions of the compilers. Compiling such methods results in different behavior of compiled and interpreted code.

and which discusses removal of dependency on class file version.

Also might be that this check will be backported - see linked tickets, e.g. https://bugs.openjdk.java.net/browse/JDK-8161989

So that we should try to find a way to compile classes (or at least test targets) into bytecode version 53 ( #411 ).

In any case - field must not be final. But unfortunately this will make FieldProbeArrayStrategy unusable for interfaces with methods, because JVMS states that

Fields of interfaces must have their ACC_PUBLIC, ACC_STATIC, and ACC_FINAL flags set

@Godin Godin added this to the 0.7.8 milestone Jul 26, 2016

@Godin Godin self-assigned this Jul 26, 2016

@bjkail

This comment has been minimized.

Show comment
Hide comment
@bjkail

bjkail Jul 28, 2016

Contributor

For interfaces, can we do similar to FieldProbeArrayStrategy except generate clinit (ala your commit 8ebd1d1) but just don't PUTSTATIC in $jacocoInit? i.e., if a static method is somehow called before the PUTSTATIC in clinit (somehow? in case something like Marc's BadCycles is possible?), then we fetch using the slow runtime indirection.

Contributor

bjkail commented Jul 28, 2016

For interfaces, can we do similar to FieldProbeArrayStrategy except generate clinit (ala your commit 8ebd1d1) but just don't PUTSTATIC in $jacocoInit? i.e., if a static method is somehow called before the PUTSTATIC in clinit (somehow? in case something like Marc's BadCycles is possible?), then we fetch using the slow runtime indirection.

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Jul 28, 2016

Member

@bjkail that's exactly what I was prototyping here = clinit + slow path, and there is no more $jacocoInit for interfaces, unless I overlooked something (we definitely should compile test classes into bytecode version 53). btw, seems that I managed to create an example similar to BadCycles, but with interfaces.

Member

Godin commented Jul 28, 2016

@bjkail that's exactly what I was prototyping here = clinit + slow path, and there is no more $jacocoInit for interfaces, unless I overlooked something (we definitely should compile test classes into bytecode version 53). btw, seems that I managed to create an example similar to BadCycles, but with interfaces.

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Jul 29, 2016

Member

@bjkail I was wrong about the example.

Member

Godin commented Jul 29, 2016

@bjkail I was wrong about the example.

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Jul 29, 2016

Member

@marchof while this request is not yet ready for code review and merge, because requires some cleanup and polishing of code, could you please have a look on idea in general to be sure that we are on a good track here and something wasn't overlooked by me? For example - maybe you know an example of "bad cycles" with interfaces?

I personally don't see other alternatives, not counting idea of "companion classes", which is anyway not ready for prime time, while this one looks quite good and really close to finalization.

Member

Godin commented Jul 29, 2016

@marchof while this request is not yet ready for code review and merge, because requires some cleanup and polishing of code, could you please have a look on idea in general to be sure that we are on a good track here and something wasn't overlooked by me? For example - maybe you know an example of "bad cycles" with interfaces?

I personally don't see other alternatives, not counting idea of "companion classes", which is anyway not ready for prime time, while this one looks quite good and really close to finalization.

@Godin Godin modified the milestones: Java 9, 0.7.8 Jul 29, 2016

@Godin Godin changed the title from FieldProbeArrayStrategy should not violate Java VM Specification to Fix instrumentation to not violate Java Virtual Machine Specification regarding initialization of final fields Aug 3, 2016

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 3, 2016

Member

@marchof IMO now this PR completely ready to be merged, so could you please review?

Member

Godin commented Aug 3, 2016

@marchof IMO now this PR completely ready to be merged, so could you please review?

@bjkail

This comment has been minimized.

Show comment
Hide comment
@bjkail

bjkail Aug 4, 2016

Contributor

FWIW, the core changes look good to me.

Contributor

bjkail commented Aug 4, 2016

FWIW, the core changes look good to me.

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 4, 2016

Member

@bjkail if my understanding of "FWIW" is correct, then - be sure your opinion matters! 😉 @marchof is probably just a bit busy being at JCrete 😆

Member

Godin commented Aug 4, 2016

@bjkail if my understanding of "FWIW" is correct, then - be sure your opinion matters! 😉 @marchof is probably just a bit busy being at JCrete 😆

@marchof

This comment has been minimized.

Show comment
Hide comment
@marchof

marchof Aug 12, 2016

Member

Tried to create a cyclic initialization example for interfaces. Results in a JVM crash: https://gist.github.com/marchof/c0ac04a2abb4b163bf410e8018a72cb7

Will report to OpenJDK.

Member

marchof commented Aug 12, 2016

Tried to create a cyclic initialization example for interfaces. Results in a JVM crash: https://gist.github.com/marchof/c0ac04a2abb4b163bf410e8018a72cb7

Will report to OpenJDK.

@bjkail

This comment has been minimized.

Show comment
Hide comment
@bjkail

bjkail Aug 12, 2016

Contributor

@Godin I assume that once OpenJDK fixes the bug that marchof found that the behavior for cyclic initialization of interfaces will have the same behavior as classes, so I guess it's best to add the slow path logic.

Contributor

bjkail commented Aug 12, 2016

@Godin I assume that once OpenJDK fixes the bug that marchof found that the behavior for cyclic initialization of interfaces will have the same behavior as classes, so I guess it's best to add the slow path logic.

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 12, 2016

Member

@marchof you can also mention that this crashes on the latest JDK 9 EA b131.

@bjkail probably yes.

Member

Godin commented Aug 12, 2016

@marchof you can also mention that this crashes on the latest JDK 9 EA b131.

@bjkail probably yes.

@marchof

This comment has been minimized.

Show comment
Hide comment
@marchof

marchof Aug 12, 2016

Member

@Godin Unfortunatelly OpenJDK-Bugs are "write once". Internal ID is JI-9042792.

Member

marchof commented Aug 12, 2016

@Godin Unfortunatelly OpenJDK-Bugs are "write once". Internal ID is JI-9042792.

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 12, 2016

Member

@marchof let me send an email ;)

Member

Godin commented Aug 12, 2016

@marchof let me send an email ;)

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 12, 2016

Member

As per comments in https://bugs.openjdk.java.net/browse/JDK-8163969 - crash is a regression introduced in 8u40. So @marchof you can try such example on 8u33 for example, I quickly tried and it seems to work fine with strategy implemented here. So I'm still not convinced that we'll need slow path 😉

Member

Godin commented Aug 12, 2016

As per comments in https://bugs.openjdk.java.net/browse/JDK-8163969 - crash is a regression introduced in 8u40. So @marchof you can try such example on 8u33 for example, I quickly tried and it seems to work fine with strategy implemented here. So I'm still not convinced that we'll need slow path 😉

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 12, 2016

Member

Elaborating a bit more: when I thought about "bad cycles" previously (if my memory is correct), then "bad cycles" for classes are possible, because they can have constructor, but not possible for interfaces, because they can't.

Member

Godin commented Aug 12, 2016

Elaborating a bit more: when I thought about "bad cycles" previously (if my memory is correct), then "bad cycles" for classes are possible, because they can have constructor, but not possible for interfaces, because they can't.

@bjkail

This comment has been minimized.

Show comment
Hide comment
@bjkail

bjkail Aug 12, 2016

Contributor

@Godin The "bad cycle" happens when a method can be invoked before clinit. If I add a clinit to JvmCrash.Target, it appears someMethod is invoked before the clinit runs, so it seems like the same issue would occur for the InterfaceFieldProbeArrayStrategy clinit?

/**
 * This snippet crashes with
 *   - Java(TM) SE Runtime Environment (8.0_101-b13) (build 1.8.0_101-b13)
 */
public class JvmCrash {

        interface Base {
                static final Object CONST = new Target(){}.someMethod();

                default void important() {
                        // Super interfaces with default methods get initialized (JLS 12.4.1)
                }
        }

        interface Target extends Base {
                static final Object CONST2 = new Object();
                default Object someMethod() {
                        new Throwable(String.valueOf(CONST2)).printStackTrace();
                        return null;
                }
        }

        public static void main(String[] args) {
                new Target() {}.someMethod();
        }

}
Contributor

bjkail commented Aug 12, 2016

@Godin The "bad cycle" happens when a method can be invoked before clinit. If I add a clinit to JvmCrash.Target, it appears someMethod is invoked before the clinit runs, so it seems like the same issue would occur for the InterfaceFieldProbeArrayStrategy clinit?

/**
 * This snippet crashes with
 *   - Java(TM) SE Runtime Environment (8.0_101-b13) (build 1.8.0_101-b13)
 */
public class JvmCrash {

        interface Base {
                static final Object CONST = new Target(){}.someMethod();

                default void important() {
                        // Super interfaces with default methods get initialized (JLS 12.4.1)
                }
        }

        interface Target extends Base {
                static final Object CONST2 = new Object();
                default Object someMethod() {
                        new Throwable(String.valueOf(CONST2)).printStackTrace();
                        return null;
                }
        }

        public static void main(String[] args) {
                new Target() {}.someMethod();
        }

}
@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 12, 2016

Member

@bjkail Probably I'm too tired and a bit rushed. Even without addition of CONST2 bad-interface-cycle.zip runs fine without JaCoCo on JDK8u25 and fails with NPE with JaCoCo version from this PR. Most likely I made a mistake when tried to add it to core test cases.

Probability to face such case seems low since crash went thru multiple JDK updates. But as now we have test case, I'm fine to re-add slow path as there is no other options. However not sure how to add test case itself since it crashes.

Member

Godin commented Aug 12, 2016

@bjkail Probably I'm too tired and a bit rushed. Even without addition of CONST2 bad-interface-cycle.zip runs fine without JaCoCo on JDK8u25 and fails with NPE with JaCoCo version from this PR. Most likely I made a mistake when tried to add it to core test cases.

Probability to face such case seems low since crash went thru multiple JDK updates. But as now we have test case, I'm fine to re-add slow path as there is no other options. However not sure how to add test case itself since it crashes.

@bjkail

This comment has been minimized.

Show comment
Hide comment
@bjkail

bjkail Aug 12, 2016

Contributor

@Godin I did think the ATHROW in JvmCrash should insert a probe, which should cause an NPE with this PR, but I didn't have an environment set up to prove it :-).

For white-box testing, perhaps create a specialized ClassVisitor/ClassWriter that returns a no-op MethodVisitor for visitMethod("<clinit>") so that the clinit is never actually inserted for the bad_cycles test? For black-box testing, perhaps parse the JVM vendor/version and whitelist the known good versions (i.e., prior to b40 and update later to allow the versions with the fix), and you could fallback to the white-box approach otherwise.

The non-interface version of the bad_cycles test added in this PR is good to have, but I think it should be moved to another test class that uses FieldProbeArrayStrategy instead.

Contributor

bjkail commented Aug 12, 2016

@Godin I did think the ATHROW in JvmCrash should insert a probe, which should cause an NPE with this PR, but I didn't have an environment set up to prove it :-).

For white-box testing, perhaps create a specialized ClassVisitor/ClassWriter that returns a no-op MethodVisitor for visitMethod("<clinit>") so that the clinit is never actually inserted for the bad_cycles test? For black-box testing, perhaps parse the JVM vendor/version and whitelist the known good versions (i.e., prior to b40 and update later to allow the versions with the fix), and you could fallback to the white-box approach otherwise.

The non-interface version of the bad_cycles test added in this PR is good to have, but I think it should be moved to another test class that uses FieldProbeArrayStrategy instead.

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 12, 2016

Member

@bjkail Even without ATHROW there should be a probe.

But there is something fishy, what makes me crazy right now, which maybe explains why at first I believed that do have an example of "bad cycles" with interfaces and then not - with current implementation on the same bad-interface-cycle.zip :

  • 1.8.0_25-b17 - NPE
  • 1.8.0_31-b13 - NPE
  • 1.8.0_40-b27 - no NPE
  • 1.8.0_45-b14 - no NPE
  • 1.8.0_102-b14 - no NPE
Member

Godin commented Aug 12, 2016

@bjkail Even without ATHROW there should be a probe.

But there is something fishy, what makes me crazy right now, which maybe explains why at first I believed that do have an example of "bad cycles" with interfaces and then not - with current implementation on the same bad-interface-cycle.zip :

  • 1.8.0_25-b17 - NPE
  • 1.8.0_31-b13 - NPE
  • 1.8.0_40-b27 - no NPE
  • 1.8.0_45-b14 - no NPE
  • 1.8.0_102-b14 - no NPE
@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 12, 2016

Member

Maybe that reason is the same as for crash... don't think I'm ready for bisection of JDK forest today 😪

Member

Godin commented Aug 12, 2016

Maybe that reason is the same as for crash... don't think I'm ready for bisection of JDK forest today 😪

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 14, 2016

Member

😆 9-ea+131 prints:

child clinit
child static method
Member

Godin commented Aug 14, 2016

😆 9-ea+131 prints:

child clinit
child static method
@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 14, 2016

Member

Reported as JI-9042842

Member

Godin commented Aug 14, 2016

Reported as JI-9042842

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 14, 2016

Member

"slow path" implemented, so @marchof could you please review?

Member

Godin commented Aug 14, 2016

"slow path" implemented, so @marchof could you please review?

@bjkail

This comment has been minimized.

Show comment
Hide comment
@bjkail

bjkail Aug 15, 2016

Contributor

InstrumentingLoader uses 4-space indentation rather than tabs. Otherwise, looks good to me.

Contributor

bjkail commented Aug 15, 2016

InstrumentingLoader uses 4-space indentation rather than tabs. Otherwise, looks good to me.

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 15, 2016

Member

@bjkail reformatted InstrumentingLoader, thx.

Member

Godin commented Aug 15, 2016

@bjkail reformatted InstrumentingLoader, thx.

@marchof

This comment has been minimized.

Show comment
Hide comment
@marchof

marchof Aug 15, 2016

Member

@Godin Thanks a lot for figuring all this out and finally resolving it! And sorry for my silence. I just started working through the change set and will drop some comments at the corresponding places.

Member

marchof commented Aug 15, 2016

@Godin Thanks a lot for figuring all this out and finally resolving it! And sorry for my silence. I just started working through the change set and will drop some comments at the corresponding places.

@@ -46,9 +47,10 @@
* callback to create the code that retrieves the reference to
* the probe array
*/
ProbeInserter(final int access, final String desc, final MethodVisitor mv,
ProbeInserter(final int access, final String name, final String desc, final MethodVisitor mv,

This comment has been minimized.

@marchof

marchof Aug 15, 2016

Member

For consistency we should also add JavaDoc for name parameter and document clinit member.

@marchof

marchof Aug 15, 2016

Member

For consistency we should also add JavaDoc for name parameter and document clinit member.

This comment has been minimized.

@Godin
@Godin

Godin Aug 15, 2016

Member

@marchof done

@@ -30,7 +30,7 @@
@Override
public MethodProbesVisitor visitMethod(final int access, final String name,
final String desc, final String signature, final String[] exceptions) {
if (!"<clinit>".equals(name)) {
if (!InstrSupport.CLINIT_NAME.equals(name)) {

This comment has been minimized.

@marchof

marchof Aug 15, 2016

Member

Oops, here we probably have an bug since we support Java 8: We should only count non abstract methods in interfaces:

if (!InstrSupport.CLINIT_NAME.equals(name) && (access & Opcodes.ACC_ABSTRACT) == 0) {
    methods = true;
}

Also we should clarify hasMethod Javadoc: true if the class has other non-abstract methods than a static initializer

@marchof

marchof Aug 15, 2016

Member

Oops, here we probably have an bug since we support Java 8: We should only count non abstract methods in interfaces:

if (!InstrSupport.CLINIT_NAME.equals(name) && (access & Opcodes.ACC_ABSTRACT) == 0) {
    methods = true;
}

Also we should clarify hasMethod Javadoc: true if the class has other non-abstract methods than a static initializer

This comment has been minimized.

@Godin

Godin Aug 15, 2016

Member

@marchof Both points are valid, however not a regression in this change as such. Also not so critical bug: previously and now - just addition of useless members.

@Godin

Godin Aug 15, 2016

Member

@marchof Both points are valid, however not a regression in this change as such. Also not so critical bug: previously and now - just addition of useless members.

This comment has been minimized.

@Godin

Godin Aug 15, 2016

Member

@marchof in fact this even doesn't lead to creation of members, because factory checks number of probes before number of methods.

@Godin

Godin Aug 15, 2016

Member

@marchof in fact this even doesn't lead to creation of members, because factory checks number of probes before number of methods.

This comment has been minimized.

@Godin

Godin Aug 15, 2016

Member

@marchof oops - it does in case of clinit+abstract methods, so ticket created - #441

@Godin

Godin Aug 15, 2016

Member

@marchof oops - it does in case of clinit+abstract methods, so ticket created - #441

This comment has been minimized.

@bjkail

bjkail Aug 15, 2016

Contributor

@Godin If an interface has <clinit> but no default methods, then the class will have probes, so the current code will unnecessarily create a field, right? I agree it's not a regression and could be fixed separately.

@bjkail

bjkail Aug 15, 2016

Contributor

@Godin If an interface has <clinit> but no default methods, then the class will have probes, so the current code will unnecessarily create a field, right? I agree it's not a regression and could be fixed separately.

This comment has been minimized.

@bjkail

bjkail Aug 15, 2016

Contributor

Oops, web UI didn't reload as you said ;-). The opened issue looks good to me.

@bjkail

bjkail Aug 15, 2016

Contributor

Oops, web UI didn't reload as you said ;-). The opened issue looks good to me.

This comment has been minimized.

@Godin

Godin Aug 15, 2016

Member

@bjkail yup, already figured this out - #434 (comment) 😉

@Godin

Godin Aug 15, 2016

Member

@bjkail yup, already figured this out - #434 (comment) 😉

import org.jacoco.core.runtime.RuntimeData;
import org.jacoco.core.runtime.SystemPropertiesRuntime;
public final class InstrumentingLoader extends ClassLoader {

This comment has been minimized.

@marchof

marchof Aug 15, 2016

Member

This is probably subject of a separate PR: Shouldn't we use this loader directly in ValidationTestBase and drop ValidationTestBase?

@marchof

marchof Aug 15, 2016

Member

This is probably subject of a separate PR: Shouldn't we use this loader directly in ValidationTestBase and drop ValidationTestBase?

This comment has been minimized.

@Godin

Godin Aug 15, 2016

Member

@marchof I suppose that you wanted to say "drop BadCycleTestBase". ValidationTestBase was quite hard to use in presence of multiple dependent classes, especially in presence of anonymous classes. And still hard to use, when multiple classes should be analyzed. Let's deal with this separately.

@Godin

Godin Aug 15, 2016

Member

@marchof I suppose that you wanted to say "drop BadCycleTestBase". ValidationTestBase was quite hard to use in presence of multiple dependent classes, especially in presence of anonymous classes. And still hard to use, when multiple classes should be analyzed. Let's deal with this separately.

This comment has been minimized.

@Godin

Godin Aug 15, 2016

Member

@marchof ticket created - #440

@Godin

Godin Aug 15, 2016

Member

@marchof ticket created - #440

@marchof

This comment has been minimized.

Show comment
Hide comment
@marchof

marchof Aug 15, 2016

Member

@Godin Ok, review done from my side, none of my 8 comments is a blocker.

P.S: Can you please check whether you see 8 comments? I only see them in the "Files changed" page, not on "Conversation".

Member

marchof commented Aug 15, 2016

@Godin Ok, review done from my side, none of my 8 comments is a blocker.

P.S: Can you please check whether you see 8 comments? I only see them in the "Files changed" page, not on "Conversation".

Do not violate JVMS regarding initialization of final fields
Without this change instrumented classes can't pass checks
and cause IllegalAccessError starting from OpenJDK 9 EA b127
(see https://bugs.openjdk.java.net/browse/JDK-8157181).
@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 15, 2016

Member

@marchof addressed all 8 comments in one way or another.

P.S. sometimes GitHub Web UI requires page reload and not just switching between tabs

Member

Godin commented Aug 15, 2016

@marchof addressed all 8 comments in one way or another.

P.S. sometimes GitHub Web UI requires page reload and not just switching between tabs

@marchof marchof merged commit 28a112c into master Aug 16, 2016

4 checks passed

continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@marchof marchof deleted the issue-434 branch Aug 16, 2016

@marchof

This comment has been minimized.

Show comment
Hide comment
@marchof

marchof Aug 16, 2016

Member

@Godin Merged! Many thanks to @Godin and @bjkail for all the investigation which was possible to resolve this - even two JDK bugs were created for this ;-)

Good to know that in the meantime we have enough knowledge in the team to work on all tricky implementation details of JaCoCo::Core.

Member

marchof commented Aug 16, 2016

@Godin Merged! Many thanks to @Godin and @bjkail for all the investigation which was possible to resolve this - even two JDK bugs were created for this ;-)

Good to know that in the meantime we have enough knowledge in the team to work on all tricky implementation details of JaCoCo::Core.

openstreetmap-mirror pushed a commit to openstreetmap/josm that referenced this pull request Aug 16, 2016

@don-vip

This comment has been minimized.

Show comment
Hide comment
@don-vip

don-vip Aug 16, 2016

We use the new 0.7.8 snapshot in JOSM that includes this PR and can confirm it works! We have a few errors caused by java.lang.IncompatibleClassChangeError, I wonder if it's a Jacoco or a Groovy issue?

The stacktrace is

java.lang.IncompatibleClassChangeError: Method org.openstreetmap.josm.gui.mappaint.mapcss.Condition.createKeyCondition(Ljava/lang/String;ZLorg/openstreetmap/josm/gui/mappaint/mapcss/Condition$KeyMatchType;Lorg/openstreetmap/josm/gui/mappai
    at org.openstreetmap.josm.gui.mappaint.mapcss.Condition$createKeyCondition.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:149)
    at org.openstreetmap.josm.gui.mappaint.mapcss.KeyConditionTest.applies_1(KeyConditionTest.groovy:81)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)

See https://josm.openstreetmap.de/jenkins/job/Java-EarlyAccess-JOSM/jdk=JDK9/lastCompletedBuild/testReport/org.openstreetmap.josm.gui.mappaint.mapcss/KeyConditionTest/applies_1/

don-vip commented Aug 16, 2016

We use the new 0.7.8 snapshot in JOSM that includes this PR and can confirm it works! We have a few errors caused by java.lang.IncompatibleClassChangeError, I wonder if it's a Jacoco or a Groovy issue?

The stacktrace is

java.lang.IncompatibleClassChangeError: Method org.openstreetmap.josm.gui.mappaint.mapcss.Condition.createKeyCondition(Ljava/lang/String;ZLorg/openstreetmap/josm/gui/mappaint/mapcss/Condition$KeyMatchType;Lorg/openstreetmap/josm/gui/mappai
    at org.openstreetmap.josm.gui.mappaint.mapcss.Condition$createKeyCondition.call(Unknown Source)
    at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
    at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:149)
    at org.openstreetmap.josm.gui.mappaint.mapcss.KeyConditionTest.applies_1(KeyConditionTest.groovy:81)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)

See https://josm.openstreetmap.de/jenkins/job/Java-EarlyAccess-JOSM/jdk=JDK9/lastCompletedBuild/testReport/org.openstreetmap.josm.gui.mappaint.mapcss/KeyConditionTest/applies_1/

@Godin

This comment has been minimized.

Show comment
Hide comment
@Godin

Godin Aug 16, 2016

Member

@don-vip There is no traces of JaCoCo in the provided stack trace, while there are clearly traces of Groovy, so very likely it is caused by Groovy. If this happens even without JaCoCo, then for sure it is caused by Groovy.

Member

Godin commented Aug 16, 2016

@don-vip There is no traces of JaCoCo in the provided stack trace, while there are clearly traces of Groovy, so very likely it is caused by Groovy. If this happens even without JaCoCo, then for sure it is caused by Groovy.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.