Support JDK 10

[Godin]

Classes of JDK 10 EA b35 use new classfile version number ( https://bugs.openjdk.java.net/browse/JDK-8188870 ) and so JaCoCo Agent 0.7.9 as well as agent from current build of master branch fail to start:

$ java -version
java version "10-ea"
Java(TM) SE Runtime Environment (build 10-ea+35)
Java HotSpot(TM) 64-Bit Server VM (build 10-ea+35, mixed mode)

$ java -javaagent:jacoco-0.7.9/lib/jacocoagent.jar     
Exception in thread "main" java.lang.reflect.InvocationTargetException
        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 java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:510)
        at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:522)
Caused by: java.lang.RuntimeException: Class java/util/UUID could not be instrumented.
        at org.jacoco.agent.rt.internal_8ff85ea.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:140)
        at org.jacoco.agent.rt.internal_8ff85ea.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:101)
        at org.jacoco.agent.rt.internal_8ff85ea.PreMain.createRuntime(PreMain.java:55)
        at org.jacoco.agent.rt.internal_8ff85ea.PreMain.premain(PreMain.java:47)
        ... 6 more
Caused by: java.lang.NoSuchFieldException: $jacocoAccess
        at java.base/java.lang.Class.getField(Class.java:1958)
        at org.jacoco.agent.rt.internal_8ff85ea.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:138)
        ... 9 more
FATAL ERROR in native method: processing of -javaagent failed

So to support JDK 10 we'll need to do similar workarounds that were done for JDK 9 in #406 and removed in #600 or wait for ASM release containing https://gitlab.ow2.org/asm/asm/merge_requests/74

[marchof]

@Godin Just a idea: Instead of implementing/removing a JavaXSupport for every Java release shoudn't we add a generic FutureJavaSupport class which internally defines what class file versions are mapped to what versions.

[Godin]

@marchof FutureJavaSupport is a good name. I want to believe that there won't be lag in ASM releases by more than one version, so this class will contain only support for one version - next one. However we won't be able to safely use "downgrade" trick in case when it's not just an increment, but a real change in bytecode, and this most likely will happen in JDK 11, and for now for me unclear what we'll do at this point.

[marchof]

for now for me unclear what we'll do at this point

Maybe one day OpenJDK will release specification before implementation... just dreaming.

[Godin]

BTW there is a trick to launch JaCoCo agent with JDK 10 EA in case when application under test doesn't have Java 10 bytecode by replacing java/util/UUID using option --patch-module:

seems that there were changes in java/util/UUID.class between JDK 8 and JDK 10 EA b35 and might be changes in future builds, so not safe to use class from rt.jar of JDK 8, but can use class from java.base.jmod of JDK 10 EA and downgrade its version by hands 😈

$ ls
jacoco-0.7.9  java.base.jmod

$ jmod extract java.base.jmod --dir java.base

$ cp java.base/classes/java/util/UUID.class .

$ printf '\x35' | dd of=UUID.class bs=1 seek=7 count=1 conv=notrunc
1+0 records in
1+0 records out
1 byte copied, 0.000121 s, 8.3 kB/s

$ mkdir -p java/util

$ mv UUID.class java/util

$ jar cf patch.jar java

$ java --patch-module java.base=patch.jar \
    -javaagent:jacoco-0.7.9/lib/jacocoagent.jar \
    --show-version Test
java 10-ea
Java(TM) SE Runtime Environment (build 10-ea+35)
Java HotSpot(TM) 64-Bit Server VM (build 10-ea+35, mixed mode)
Error: Could not find or load main class Test
Caused by: java.lang.ClassNotFoundException: Test

$ ls *.exec
jacoco.exec

We'll be using java/lang/UnknownError.class after #555 and seems that it had no changes since 2008 (JDK 7) and just addition of serialVersionUID before, so chance of changes seems to be quite low, so quite safe to take it from rt.jar of JDK 8 or at least more safer than in case of java/uitl/UUID.class.

[don-vip]

ASM 6.1 beta has been released: http://central.maven.org/maven2/org/ow2/asm/asm/6.1-beta/

[Godin]

@don-vip we know 😉 and it breaks our tests, for the time being have strong feeling that there is regression on their side, but still investigating. Anyway thanks for notification 👍

[Godin]

For the record regression that breaks our tests - https://gitlab.ow2.org/asm/asm/issues/317805
Nashorn also encountered some regressions. Seems that the same one, but maybe also others - https://mail.ow2.org/wws/arc/asm/2018-01/msg00003.html

Looks like our main code is not affected, but given massive refactorings in this version, presence of this regression and the need to disable affected tests as its consequence, reduce confidence.

Also don't know if possible to add beta versions into Eclipse Orbit (for Eclipse EclEmma), but given the above I don't think that this even deserves to be investigated.

So for now for JaCoCo and for EclEmma still might be safer to do a workaround with ASM 6.0. BTW tried different than before approach for workaround and fortunately accidentally found https://gitlab.ow2.org/asm/asm/issues/317807

And BTW in context of JDK 10 the following regression in javac should be mentioned - https://bugs.openjdk.java.net/browse/JDK-8193449 , which is still not resolved.

@don-vip feel free to do your own build of JaCoCo with ASM 6.1-beta and test it on your projects:
mvn install -DskiptTests after

diff --git org.jacoco.build/pom.xml org.jacoco.build/pom.xml
index d5f911e4..df39b903 100644
--- org.jacoco.build/pom.xml
+++ org.jacoco.build/pom.xml
@@ -141,7 +141,7 @@
     <argLine>${jvm.args}</argLine>
 
     <!-- Dependencies versions -->
-    <asm.version>6.0</asm.version>
+    <asm.version>6.1-beta</asm.version>
     <ant.version>1.7.1</ant.version>
     <args4j.version>2.0.28</args4j.version>
     <junit.version>4.8.2</junit.version>
@@ -666,7 +666,7 @@
             </Export-Package>
             <Import-Package>
               org.jacoco.*;version="${range;[===,==+);${Bundle-Version}}",
-              org.objectweb.asm.*;version="${range;[===,=+);${asm.version}}"
+              org.objectweb.asm.*;version="${range;[===,=+);6.1}"
             </Import-Package>
             <Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-RequiredExecutionEnvironment>
             <Eclipse-SourceReferences>scm:git:git://github.com/jacoco/jacoco.git;path="${project.artifactId}";commitId=${buildNumber}</Eclipse-SourceReferences>
diff --git org.jacoco.core/src/org/jacoco/core/internal/ContentTypeDetector.java org.jacoco.core/src/org/jacoco/core/internal/ContentTypeDetector.java
index ae665624..324ba36a 100644
--- org.jacoco.core/src/org/jacoco/core/internal/ContentTypeDetector.java
+++ org.jacoco.core/src/org/jacoco/core/internal/ContentTypeDetector.java
@@ -83,6 +83,7 @@ public class ContentTypeDetector {
                        case Opcodes.V1_7:
                        case Opcodes.V1_8:
                        case Opcodes.V9:
+                       case Opcodes.V10:
                                return CLASSFILE;
                        }
                }

[don-vip]

@Godin : we now use the latest snapshot versions of jacoco (patched as above) & asm (built manually) and it works! Thank you :)

[olamy]

Hi @Godin
As jdk10 is just around the corner :-), I wonder if you have any plan for a release?
Cheers

[olamy]

Hi
I just did some testing with jdk10 and I got this failure:

/bin/sh -c cd /Users/olamy/dev/sources/open-sources/jetty/jetty.project/jetty-util && /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home/bin/java '-javaagent:/Users/olamy/repository/org/jacoco/org.jacoco.agent/0.8.1-SNAPSHOT/org.jacoco.agent-0.8.1-SNAPSHOT-runtime.jar=destfile=/Users/olamy/dev/sources/open-sources/jetty/jetty.project/jetty-util/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:**/org/eclipse/jetty/maven/**:**/org/eclipse/jetty/jspc/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**' -Dfile.encoding=UTF-8 -Duser.language=en -Duser.region=US -showversion -Xmx1g -Xms1g -XX:+PrintGCDetails
[0.002s][warning][gc] -XX:+PrintGCDetails is deprecated. Will use -Xlog:gc* instead.
[0.010s][info   ][gc,heap] Heap region size: 1M
[0.025s][info   ][gc     ] Using G1
[0.025s][info   ][gc,heap,coops] Heap address: 0x0000000780000000, size: 1024 MB, Compressed Oops mode: Zero based, Oop shift amount: 3
Exception in thread "main" java.lang.reflect.InvocationTargetException
	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 java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:510)
	at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:522)
Caused by: java.lang.RuntimeException: Class java/lang/UnknownError could not be instrumented.
	at org.jacoco.agent.rt.internal_cbf3dbc.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:139)
	at org.jacoco.agent.rt.internal_cbf3dbc.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:100)
	at org.jacoco.agent.rt.internal_cbf3dbc.PreMain.createRuntime(PreMain.java:55)
	at org.jacoco.agent.rt.internal_cbf3dbc.PreMain.premain(PreMain.java:47)
	... 6 more
Caused by: java.lang.NoSuchFieldException: $jacocoAccess
	at java.base/java.lang.Class.getField(Class.java:1958)
	at org.jacoco.agent.rt.internal_cbf3dbc.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:137)
	... 9 more
FATAL ERROR in native method: processing of -javaagent failed
Abort trap: 6

[huxi]

org.ow2.asm:asm:6.1-beta2 was released a few days ago. It looks like the open issues mentioned above have been resolved.

[sormuras]

Perhaps JDK 11 can be supported too? EA versions are available at http://jdk.java.net/11/

[don-vip]

@Godin I tried to define the V11 opcode myself in a patched version of jacoco but this is not enough, I face this error (NoSuchFieldException: $jacocoAccess) again with JDK11. Do we have to wait 6 months for next ASM version, or is there another magic trick?

[don-vip]

ASM 6.1 has been released.

[Godin]

@don-vip

I tried to define the V11 opcode myself in a patched version of jacoco but this is not enough

Of course this is not enough, because ASM 6.1 does not support Java 11 bytecode: as was stated in #629 (comment) bytecode version 11 is not just an increment, but a real change - more specifically JEP 309 scheduled on JDK 11 and will introduce new class-file constants, which must be properly read and written by ASM, which requires changes in ASM. So we can't support instrumentation of Java 11 bytecode without changes in ASM. Maybe we can support execution under JDK 11, but as was stated in #629 (comment) this requires some development and testing.

Also speaking in general, don't you think that pressuring us about support of something that was not released sounds a bit strange? This sounds like asking for proper support of Java 9 at a time of Java 5 release. Please also have in mind that we maintain JaCoCo in a free time, and have other projects and personal lives.

ASM 6.1 has been released.

Thank you everybody for all the notifications with news about ASM, but please stop - we know all these news directly from the ASM mailing list and even monitor changes in theirs Git and issue tracker. Same for notifications about news in JDK world and its Early Access builds - we regularly test EAs, specifically we investigated and reported several regressions in 10 as well as tested their resolutions, which btw also consumes our time.

As was stated before (#629 (comment)) upgrade of ASM version in JaCoCo requires availability of that version for Eclipse EclEmma and work on this was started at the day of release of ASM - https://bugs.eclipse.org/bugs/show_bug.cgi?id=532291

All in all - we do plan release with Java 10 support and after that do plan to work on Java 11 support, please be a bit patient.

Thank you for your understanding.

[don-vip]

@Godin Thank you for your very detailed answer and please accept my apologies, I didn't want to upset you in any way. I'm going to disable coverage for Java >= 11 and patiently wait for an update 👍

[ijuma]

This is going to come up a lot with Java's new release cadence. Projects want to ensure that the Java release in development doesn't cause regressions. I suggest adding a note to the Readme that the recommended approach is to disable coverage for unsupported Java versions as it may take a while due to the reasons outlined by @Godin.

[Godin]

@marchof while I started process of addition of ASM 6.1 into Eclipse Orbit and CQ was already accepted, I'm not convinced that for support of Java 10 we should use it.

Besides a new V10 constant for Java 10 class files, there are no new features compared to 6.0. However, internally, a lot of changes have been made

Not counting V10 constant seems that the only interesting thing is a fix of regression introduced in 6.0 that we observed during previous upgrade

Resizing jump instruction adds invalid stack frame to a class without frames

and the rest is massive rewrite of 6.0 that is bugs/regressions prone. Here is concrete example uncovered today while playing with EclEmma on some Eclipse projects, unfortunately after 6.1 release and already reported as https://gitlab.ow2.org/asm/asm/issues/317815

import java.lang.annotation.*;

class Example {
  @Documented
  @Retention(value=RetentionPolicy.CLASS)
  @Target(value=ElementType.TYPE_USE)
  @interface NonNull {
  }

  void fun() {
    @NonNull Object o = legacy();
  }

  Object legacy() {
    return new Object();
  }
}

current version of JaCoCo based on ASM 6.0 and hence EclEmma perfectly able to instrument this class, however JaCoCo and EclEmma after upgrade fail with NPE in ClassReader exactly as described in the above ticket. AFAIK widely used in Eclipse community annotation NonNull is runtime invisible and can be applied on local variables exactly as in above example. While I don't know how often it is actually used for local variables, documentation states

local variables typically don't even need these, but may also leverage null annotations for bridging between annotated code and "legacy" code

To sum up - as of today options for Java 10 (GA 2018/03/20) support in JaCoCo:

• go ahead with 6.1
• ask/wait a bit more whether 6.1.1 will quickly follow
• I have an implementation of trick with downgrade, of course more careful than the one that was done for Java 9

According to https://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire in case of first two options CQ won't be needed once service release is available.

In first case JaCoCo will get regression that known in advance and that might turn out to be serious, so also risk that we'll not update JaCoCo in EclEmma for Java 10 support.

In second case still risk that some other regression will sneak into Photon EPP (GA 2018/06/27) till Photon.1 in September.

Can polish/prepare third option this week and we will able to decide between it and second to release JaCoCo before/at same time as JDK 10.

So, @marchof , WDYT?

[Godin]

@marchof I think all comments were addressed, so could you please re-review?

[marchof]

@Godin Done, thanks!

[olamy]

thanks guys for your hard work I just tested a build and everything works fine!!
Thanks again!!

[Godin]

Now that JaCoCo 0.8.1 with Java 10 support has been released, can think of Java 11. And here is question to you guys @don-vip @ijuma @sormuras : do you compile into bytecode version 55 (Java 11) or just run under JDK 11 EA ? The reason for this question is that the second case is easier and maybe could be possible to implement before ASM release.

[sormuras]

"JUnit 5" uses --release 9 for a single module and --release 8 for the rest.

I will test our build against JaCoCo 0.8.1 tonight and report back here.

[Godin]

@sormuras just to be sure that there is no misunderstanding: JaCoCo 0.8.1 supports bytecode versions from 45 (Java 1.1) to 54 (Java 10) and runs under JDKs from 5 to 10, and doesn't run under JDK 11 EA. My question about 11 EA is for our future work.

[ijuma]

@Godin We use --release 7 (soon planning to switch to --release 8) in Kafka. We just want to be able to compile and run the tests with Java 9, 10 and (soon) 11 to ensure that we catch any problems early.

[sormuras]

@sormuras just to be sure that there is no misunderstanding: JaCoCo 0.8.1 supports bytecode versions from 45 (Java 1.1) to 54 (Java 10) and runs under JDKs from 5 to 10, and doesn't run under JDK 11 EA. My question about 11 EA is for our future work.

Understood.

We're using OracleJDK 9 and OpenJDK 10 to build and test JUnit 5 at the moment: https://travis-ci.org/junit-team/junit5/builds/355963543 -- JaCoCo is only activated when running with 9. This might change tonight, after upgrading to JaCoCo 0.8.1

11-ea is blocked by gradle/gradle#4515 ... was blocked! Waiting for Gradle 4.7-RC1 now, and JaCoCo 0.8.2? 😉

[sormuras]

fyi, JaCoCo 0.8.1 works like a charm on OpenJDK 10: https://codecov.io/gh/junit-team/junit5/list/0bb65c5b945e3cfbb7c99ded92b80b96642e96e6/

[Godin]

@don-vip have you lost initial interest about JDK 11 EA ? 😉 or my earlier comment offended you? if so I sincerely apologize. Could you please answer on #629 (comment)

[don-vip]

@Godin I'm neither offended (don't worry :)) nor lost interest in JDK 11, I simply didn't see the Github notification :) To answer your question, our build compiles and runs tests using the same JDK. So for JDK 11, we compile our classes with JDK11 and run tests with it too. We faced the same error than previously with JDK 10 (NoSuchFieldException: $jacocoAccess) so for now, I have disabled jacoco coverage in our JDK 11 build, and things are going smoothly. I will be happy to enable it again once you have preliminary support for JDK 11 bytecode.