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

Support JDK 10 #629

Merged
merged 1 commit into from Mar 21, 2018

Conversation

Projects
7 participants
@Godin
Member

Godin commented Mar 18, 2018

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

This comment has been minimized.

Member

marchof commented Dec 11, 2017

@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

This comment has been minimized.

Member

Godin commented Dec 11, 2017

@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

This comment has been minimized.

Member

marchof commented Dec 11, 2017

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

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

@Godin

This comment has been minimized.

Member

Godin commented Dec 14, 2017

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

This comment has been minimized.

don-vip commented Jan 6, 2018

@Godin

This comment has been minimized.

Member

Godin commented Jan 6, 2018

@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

This comment has been minimized.

Member

Godin commented Jan 9, 2018

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;
                        }
                }

simon04 pushed a commit to openstreetmap/josm that referenced this pull request Jan 11, 2018

see #15560 - custom version of jacoco 0.8.1-SNAPSHOT (8685ca83dd562f3…
…df9d2c8221ed5b928b36ebf62 + patch) + asm 6.1-beta (58b93c69)

see jacoco/jacoco#629 (comment)

git-svn-id: http://josm.openstreetmap.de/svn/trunk@13305 0c6e7542-c601-0410-84e7-c038aed88b3b
@don-vip

This comment has been minimized.

don-vip commented Jan 11, 2018

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

floscher pushed a commit to floscher/josm that referenced this pull request Jan 11, 2018

see #15560 - custom version of jacoco 0.8.1-SNAPSHOT (8685ca83dd562f3…
…df9d2c8221ed5b928b36ebf62 + patch) + asm 6.1-beta (58b93c69)

see jacoco/jacoco#629 (comment)

git-svn-id: https://josm.openstreetmap.de/svn/trunk@13305 0c6e7542-c601-0410-84e7-c038aed88b3b

@Godin Godin self-assigned this Feb 2, 2018

@Godin Godin added this to To Do in JDK 10 Feb 2, 2018

@olamy

This comment has been minimized.

olamy commented Feb 8, 2018

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

@olamy

This comment has been minimized.

olamy commented Feb 8, 2018

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

This comment has been minimized.

huxi commented Feb 8, 2018

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 added a commit to junit-team/junit5-samples that referenced this pull request Mar 1, 2018

@sormuras

This comment has been minimized.

sormuras commented Mar 1, 2018

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

@don-vip

This comment has been minimized.

don-vip commented Mar 4, 2018

@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

This comment has been minimized.

don-vip commented Mar 13, 2018

ASM 6.1 has been released.

@Godin

This comment has been minimized.

Member

Godin commented Mar 13, 2018

@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

This comment has been minimized.

don-vip commented Mar 13, 2018

@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 comment has been minimized.

ijuma commented Mar 13, 2018

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

This comment has been minimized.

Member

Godin commented Mar 14, 2018

@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?

floscher pushed a commit to floscher/josm that referenced this pull request Mar 14, 2018

mfussenegger added a commit to crate/crate that referenced this pull request Mar 14, 2018

mfussenegger added a commit to crate/crate that referenced this pull request Mar 15, 2018

@Godin

This comment has been minimized.

Member

Godin commented Mar 20, 2018

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

@Godin Godin referenced this pull request Mar 20, 2018

Merged

Remove PatchedClassReader #4772

@marchof marchof merged commit e068166 into master Mar 21, 2018

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-629 branch Mar 21, 2018

@marchof

This comment has been minimized.

Member

marchof commented Mar 21, 2018

@Godin Done, thanks!

@olamy

This comment has been minimized.

olamy commented Mar 21, 2018

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

@Godin Godin moved this from In progress to Done in JDK 10 Mar 21, 2018

@offa offa referenced this pull request Mar 22, 2018

Closed

Add JDK10 Support #49

@Godin

This comment has been minimized.

Member

Godin commented Mar 22, 2018

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

This comment has been minimized.

sormuras commented Mar 22, 2018

"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

This comment has been minimized.

Member

Godin commented Mar 22, 2018

@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

This comment has been minimized.

ijuma commented Mar 22, 2018

@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

This comment has been minimized.

sormuras commented Mar 22, 2018

@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

This comment has been minimized.

sormuras commented Mar 22, 2018

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

mfussenegger added a commit to crate/crate that referenced this pull request Mar 26, 2018

@Godin

This comment has been minimized.

Member

Godin commented Mar 29, 2018

@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

This comment has been minimized.

don-vip commented Mar 29, 2018

@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.

simon04 pushed a commit to openstreetmap/josm that referenced this pull request Mar 30, 2018

pyokagan added a commit to pyokagan/addressbook-level4 that referenced this pull request May 7, 2018

build.gradle: use JaCoCo 0.8.1
With JDK 10, `./gradlew allTest` fails to run any tests, instead spewing
out the following errors on the console:

    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)
    FATAL ERROR in native method: processing of -javaagent failed
            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_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:139)
            at org.jacoco.agent.rt.internal_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:100)
            at org.jacoco.agent.rt.internal_290345e.PreMain.createRuntime(PreMain.java:55)
            at org.jacoco.agent.rt.internal_290345e.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_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:137)
            ... 9 more

... and so forth

According to a PR[1] on the JaCoCo's issue tracker, this occurs because
"Classes of JDK 10 EA b35 use a new classfile version number and so
JaCoCo Agent 0.7.9 as well as agent from current build of master branch
fail to start". This has been fixed as of JaCoCo 0.8.1, which also
happens to be the latest release.

We do not explicitly specify the version JaCoCo to use in our
build.gradle file, and so the `jacoco` gradle plugin just uses its
default, which happens to be `0.8.0` on Gradle 4.6 (the version we are
using). This version of JaCoCo still has this bug, and so we get the
errors.

Fix this by explicitly telling the gradle jacoco plugin to use JaCoCo
version 0.8.1.

[1] jacoco/jacoco#629

pyokagan added a commit to pyokagan/addressbook-level4 that referenced this pull request May 7, 2018

build.gradle: use JaCoCo 0.8.1
With JDK 10, `./gradlew allTest` fails to run any tests, instead spewing
out the following errors on the console:

    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)
    FATAL ERROR in native method: processing of -javaagent failed
            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_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:139)
            at org.jacoco.agent.rt.internal_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:100)
            at org.jacoco.agent.rt.internal_290345e.PreMain.createRuntime(PreMain.java:55)
            at org.jacoco.agent.rt.internal_290345e.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_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:137)
            ... 9 more

... and so forth

According to a PR[1] on the JaCoCo's issue tracker, this occurs because
"Classes of JDK 10 EA b35 use a new classfile version number and so
JaCoCo Agent 0.7.9 as well as agent from current build of master branch
fail to start". This has been fixed as of JaCoCo 0.8.1, which also
happens to be the latest release.

We do not explicitly specify the version JaCoCo to use in our
build.gradle file, and so the `jacoco` gradle plugin just uses its
default, which happens to be 0.8.0[2] on Gradle 4.6 (the version we are
using). This version of JaCoCo still has this bug, and so we get the
errors.

Fix this by explicitly telling the gradle jacoco plugin to use JaCoCo
version 0.8.1.

[1] jacoco/jacoco#629
[2] gradle/gradle@8a09484

pyokagan added a commit to pyokagan/addressbook-level4 that referenced this pull request May 7, 2018

build.gradle: use JaCoCo 0.8.1
With JDK 10, `./gradlew allTest` fails to run any test, instead spewing
out the following errors on the console:

    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)
    FATAL ERROR in native method: processing of -javaagent failed
            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_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:139)
            at org.jacoco.agent.rt.internal_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:100)
            at org.jacoco.agent.rt.internal_290345e.PreMain.createRuntime(PreMain.java:55)
            at org.jacoco.agent.rt.internal_290345e.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_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:137)
            ... 9 more

... and so forth

According to a PR[1] on the JaCoCo's issue tracker, this occurs because
"Classes of JDK 10 EA b35 use a new classfile version number and so
JaCoCo Agent 0.7.9 as well as agent from current build of master branch
fail to start". This has been fixed as of JaCoCo 0.8.1, which also
happens to be the latest release.

We do not explicitly specify the version JaCoCo to use in our
build.gradle file, and so the `jacoco` gradle plugin just uses its
default, which happens to be 0.8.0[2] on Gradle 4.6 (the version we are
using). This version of JaCoCo still has this bug, and so we get the
errors.

Fix this by explicitly telling the gradle jacoco plugin to use JaCoCo
version 0.8.1.

[1] jacoco/jacoco#629
[2] gradle/gradle@8a09484

pyokagan added a commit to pyokagan/addressbook-level4 that referenced this pull request May 7, 2018

build.gradle: use JaCoCo 0.8.1
With JDK 10, `./gradlew allTest` fails to run tests, instead spewing out
the following errors on the console:

    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)
    FATAL ERROR in native method: processing of -javaagent failed
            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_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:139)
            at org.jacoco.agent.rt.internal_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:100)
            at org.jacoco.agent.rt.internal_290345e.PreMain.createRuntime(PreMain.java:55)
            at org.jacoco.agent.rt.internal_290345e.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_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:137)
            ... 9 more

... and so forth

According to a PR[1] on the JaCoCo's issue tracker, this occurs because
"Classes of JDK 10 EA b35 use a new classfile version number and so
JaCoCo Agent 0.7.9 as well as agent from current build of master branch
fail to start". This has been fixed as of JaCoCo 0.8.1, which also
happens to be the latest release.

We do not explicitly specify the version JaCoCo to use in our
build.gradle file, and so the `jacoco` gradle plugin just uses its
default, which happens to be 0.8.0[2] on Gradle 4.6 (the version we are
using). This version of JaCoCo still has this bug, and so we get these
errors.

Fix this by explicitly telling the gradle jacoco plugin to use JaCoCo
version 0.8.1.

[1] jacoco/jacoco#629
[2] gradle/gradle@8a09484

pyokagan added a commit to pyokagan/addressbook-level4 that referenced this pull request Jun 30, 2018

Gradle wrapper: upgrade to Gradle 4.8.1
With JDK 10, `./gradlew allTest` fails to run tests, instead spewing out
the following errors on the console:

    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)
    FATAL ERROR in native method: processing of -javaagent failed
            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_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:139)
            at org.jacoco.agent.rt.internal_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:100)
            at org.jacoco.agent.rt.internal_290345e.PreMain.createRuntime(PreMain.java:55)
            at org.jacoco.agent.rt.internal_290345e.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_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:137)
            ... 9 more

... and so forth

According to a PR[1] on the JaCoCo's issue tracker, this occurs because
"Classes of JDK 10 EA b35 use a new classfile version number and so
JaCoCo Agent 0.7.9 as well as agent from current build of master branch
fail to start". This has been fixed as of JaCoCo 0.8.1, which also
happens to be the latest release.

We do not explicitly specify the version JaCoCo to use in our
build.gradle file, and so the `jacoco` gradle plugin just uses its
default, which happens to be 0.8.0[2] on Gradle 4.6 (the version we are
using). This version of JaCoCo still has this bug, and so we get these
errors.

Fix this by upgrading to the latest version of Gradle (4.8.1). Since
Gradle 4.7[3] the default JaCoCo plugin has been upgraded to version
0.8.1, and so upgrading to the latest version of Gradle will fix this
problem and allow us to run tests on JDK 10.

The Gradle wrapper upgrade was performed by running the command:

    ./gradlew wrapper --gradle-version 4.8.1

and then converting the line endings of gradlew.bat to unix to satisfy
our travis line ending checks.

[1] jacoco/jacoco#629
[2] gradle/gradle@8a09484
[3] https://docs.gradle.org/4.7/release-notes.html#default-jacoco-version-upgraded-to-0.8.1

pyokagan added a commit to pyokagan/addressbook-level4 that referenced this pull request Jul 3, 2018

Gradle wrapper: upgrade to Gradle 4.8.1
With JDK 10, `./gradlew allTest` fails to run tests, instead spewing out
the following errors on the console:

    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)
    FATAL ERROR in native method: processing of -javaagent failed
            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_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:139)
            at org.jacoco.agent.rt.internal_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:100)
            at org.jacoco.agent.rt.internal_290345e.PreMain.createRuntime(PreMain.java:55)
            at org.jacoco.agent.rt.internal_290345e.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_290345e.core.runtime.ModifiedSystemClassRuntime.createFor(ModifiedSystemClassRuntime.java:137)
            ... 9 more

... and so forth

According to a PR[1] on the JaCoCo's issue tracker, this occurs because
"Classes of JDK 10 EA b35 use a new classfile version number and so
JaCoCo Agent 0.7.9 as well as agent from current build of master branch
fail to start". This has been fixed as of JaCoCo 0.8.1, which also
happens to be the latest release.

We do not explicitly specify the version JaCoCo to use in our
build.gradle file, and so the `jacoco` gradle plugin just uses its
default, which happens to be 0.8.0[2] on Gradle 4.6 (the version we are
using). This version of JaCoCo still has this bug, and so we get these
errors.

Fix this by upgrading to the latest version of Gradle (4.8.1). Since
Gradle 4.7[3] the default JaCoCo plugin has been upgraded to version
0.8.1, and so upgrading to the latest version of Gradle will fix this
problem and allow us to run tests on JDK 10.

The Gradle wrapper upgrade was performed by running the command:

    ./gradlew wrapper --gradle-version 4.8.1

and then converting the line endings of gradlew.bat to unix to satisfy
our travis line ending checks.

Also, update any references to the Gradle version we are using in the
code base to 4.8.1.

[1] jacoco/jacoco#629
[2] gradle/gradle@8a09484
[3] https://docs.gradle.org/4.7/release-notes.html#default-jacoco-version-upgraded-to-0.8.1

@jacoco jacoco locked as resolved and limited conversation to collaborators Oct 8, 2018

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