Java 9 compatibility - Githubissues

leventov commented 8 years ago

java.lang.IllegalAccessError: class net.openhft.chronicle.core.OS (in unnamed module @0x42d1c1ef) cannot access class sun.nio.ch.FileChannelImpl (in module java.base) because module java.base does not export sun.nio.ch to unnamed module @0x42d1c1ef
        at net.openhft.chronicle.core.OS.<clinit>(OS.java:67)

Java:

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

peter-lawrey commented 8 years ago

There should be a command line option to allow this access for backward compatibility.

On 18 July 2016 at 11:40, Roman Leventov notifications@github.com wrote:

java.lang.IllegalAccessError: class net.openhft.chronicle.core.OS (in unnamed module @0x42d1c1ef) cannot access class sun.nio.ch.FileChannelImpl (in module java.base) because module java.base does not export sun.nio.ch to unnamed module @0x42d1c1ef at net.openhft.chronicle.core.OS.(OS.java:67)

Java:

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenHFT/Chronicle-Core/issues/15, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBU8bKSrKc5kw7GQS_YaU3MbUCN9oRFks5qW1gCgaJpZM4JOl3a .

scottkidder commented 7 years ago

-XaddExports:java.base/sun.nio.ch=ALL-UNNAMED or -XaddExports:java.base/jdk.internal.ref=ALL-UNNAMED

MartyIX commented 7 years ago

Hi @epickrram ,

I've noticed there is a new Java-9 branch. I've being trying to make CQ work with Java 9 for quite a while. The following repos passes(*) tests on Java 9.

https://github.com/MartyIX/Chronicle-Core/tree/JDK-9
https://github.com/MartyIX/Chronicle-Bytes/tree/JDK-9-clean
https://github.com/MartyIX/Chronicle-Wire/tree/JDK-9-clean (* 1 tests fails but it may be what master branch does at the moment.)

My goal was to learn something new. I certainly don't claim the modifications are of any use. Maybe they are, maybe they are not. I was totally unfamiliar with the code at the beginning.

Regards, Martin

peter-lawrey commented 7 years ago

Hello, Mark Price is looking into this on our side but us away this week. Will get him to look into it when he get back.

Regards Peter.

On 16 Aug. 2017 06:14, "Martin Vseticka" notifications@github.com wrote:

Hi @epickrram https://github.com/epickrram ,

I've noticed there is new Java-9 branch. I've being trying to make CQ work with Java 9 for quite a while. The following repos passes(*) tests on Java 9.

https://github.com/MartyIX/Chronicle-Core/tree/JDK-9

https://github.com/MartyIX/Chronicle-Bytes/tree/JDK-9-clean

https://github.com/MartyIX/Chronicle-Wire/tree/JDK-9-clean (* 1 tests fails but it may be what master branch does at the moment.)

My goal was to learn something new. I certainly don't claim the modifications are of any use. Maybe they are, maybe they are not. I was totally unfamiliar with the code at the beginning.

Regards, Martin

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/OpenHFT/Chronicle-Core/issues/15#issuecomment-322726874, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBU8RfSthoCO97D6hO84BTEy3xNuRY5ks5sYsEDgaJpZM4JOl3a .

MartyIX commented 7 years ago

@epickrram Can I help somehow with JDK-9 support?

epickrram commented 7 years ago

Hi @MartyIX I'll be picking this work up shortly. I'll review your changes and get back to you.

epickrram commented 7 years ago

I think we'll want to maintain support for both java 8 & java 9 on the same master branch, rather than having multiple branches.

I've committed changes to Chronicle-Core that allow it to build on java 9 without any special modifications. The java 9-specific code is hidden behind Jvm.isJava9Plus().

Because of the need to maintain API compatibility between different libraries, it's going to be necessary to use existing APIs such as StringUtils.extractChars in Chronicle-Bytes, etc. In future, these may be special-cased for performance, but for now, just getting everything to build on java 8 & 9 is enough to be getting on with.

Unfortunately, that means that your work is not compatible with the direction I think we'll take. I've made similar changes to Chronicle-Bytes and Chronicle-Wire allowing them to be build with java 9:

mvn -P java9 test

If you'd be happy to redo some of the work against the master branch of -Bytes or -Wire, such that it will build on either java 8 or java 9, then please submit a pull-request for review.

If so, you'll need to run mvn install -P java9 in Chronicle-Core, and override the chronicle-core artifact version in (e.g.) Chronicle-Bytes.

MartyIX commented 7 years ago

@epickrram When I run mvn -P java9 clean install I get the following warning when tests run:

[main] WARN net.openhft.chronicle.core.cleaner.CleanerServiceLocator - Error while trying to load service providers
java.util.ServiceConfigurationError: net.openhft.chronicle.core.cleaner.spi.ByteBufferCleanerService: Provider net.openhft.chronicle.core.cleaner.impl.jdk8.Jdk8ByteBufferCleanerService not found
    at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:588)
    at java.base/java.util.ServiceLoader.access$200(ServiceLoader.java:390)
    at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1206)
    at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1215)
    at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1259)
    at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1294)
    at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1379)
    at net.openhft.chronicle.core.cleaner.CleanerServiceLocator.cleanerService(CleanerServiceLocator.java:27)
    at net.openhft.chronicle.core.io.IOTools.clean(IOTools.java:167)
    at net.openhft.chronicle.core.io.IOToolsTest.shouldCleanDirectBuffer(IOToolsTest.java:10)
    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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
    at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
[main] WARN net.openhft.chronicle.core.cleaner.CleanerServiceLocator - Unable to find suitable cleaner service, falling back to using reflection

For some reason ServiceLoader knows about Jdk8ByteBufferCleanerService even though the class should be excluded in pom.xml: https://github.com/OpenHFT/Chronicle-Core/blob/master/pom.xml#L214

epickrram commented 7 years ago

I think it's failing to filter out the services.properties in META-INF. Will take a look.

epickrram commented 7 years ago

Should be fixed in 3e5695e

MartyIX commented 7 years ago

Yes, it seems to be OK now. Thanks.

MartyIX commented 7 years ago

@epickrram Is there a roadmap for JDK 9 support? Can I help with testing/fixing somehow?

PS: I sent a PR for Chronicle-Threads: https://github.com/OpenHFT/Chronicle-Threads/pull/10 that should get rid of the exception of the javadoc task.

epickrram commented 7 years ago

Not so much a roadmap, more a need to make sure that all the OpenHFT projects build/execute on JDK9.

Since I don't really know what all the problems are going to be yet, it's hard to figure out exactly what will be required.

If you'd like to help, then discovering and raising issues against the OpenHFT projects would be a good start. Feel free to fix any problems you find ;)

In terms of ordering, projects should be validated in the order that they appear in this file:

https://github.com/OpenHFT/OpenHFT/blob/master/chronicle-bom/pom.xml#L43

We'll want to first deal with any breaking API changes (i.e. the char[] -> bytes[] change), so that the code can run on either Java8 or Java9. Any Java9-specific features will end up as a Jigsaw module for Java9 in this repo:

https://github.com/OpenHFT/Chronicle-JDK9

MartyIX commented 7 years ago

Well, I tried to build CQ with the latest -Core, -Bytes and -Wire and it seems to work on JDK 9. However, I must admit I don't use unicode characters. However, I'm happy it works for me anyway.

RobAustin commented 7 years ago

thanks for your feedback

On 18 Sep 2017, at 14:20, Martin Vseticka notifications@github.com wrote:

Well, I tried to build CQ with the latest -Core, -Bytes and -Wire and it seems to work on JDK 9. However, I must admit I don't use unicode characters. However, I'm happy it works for me anyway.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenHFT/Chronicle-Core/issues/15#issuecomment-330217899, or mute the thread https://github.com/notifications/unsubscribe-auth/AGNGSJICJGhQ6YbEUgc4wjdlaGbEB1tmks5sjm4dgaJpZM4JOl3a.

MartyIX commented 6 years ago

Apache Maven Javadoc 3.0.0 was released. So it can be changed here: https://github.com/OpenHFT/Chronicle-Core/blob/master/pom.xml#L89

Still I get the following errors when compiling with Java 9:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.0.0:jar (attach-javadocs) on project chronicle-core: MavenReportException: Error while generating Javadoc: 
[ERROR] Exit code: 1 - /home/marty/work/Chronicle-Core/src/main/java/net/openhft/chronicle/core/OS.java:24: error: package sun.nio.ch is not visible
[ERROR] import sun.nio.ch.FileChannelImpl;
[ERROR]               ^
[ERROR]   (package sun.nio.ch is declared in module java.base, which does not export it to the unnamed module)
[ERROR] /home/marty/work/Chronicle-Core/src/main/java/net/openhft/chronicle/core/cleaner/impl/reflect/ReflectionBasedByteBufferCleanerService.java:7: error: package sun.nio.ch is not visible
[ERROR] import sun.nio.ch.DirectBuffer;
[ERROR]               ^
[ERROR]   (package sun.nio.ch is declared in module java.base, which does not export it to the unnamed module)
[ERROR] /home/marty/work/Chronicle-Core/src/main/java/net/openhft/chronicle/core/cleaner/impl/jdk8/Jdk8ByteBufferCleanerService.java:5: error: package sun.nio.ch is not visible
[ERROR] import sun.nio.ch.DirectBuffer;
[ERROR]               ^
[ERROR]   (package sun.nio.ch is declared in module java.base, which does not export it to the unnamed module)
[ERROR] /home/marty/work/Chronicle-Core/src/main/java/net/openhft/chronicle/core/tcp/FastJ8SocketChannel.java:5: error: package sun.nio.ch is not visible
[ERROR] import sun.nio.ch.DirectBuffer;
[ERROR]               ^
[ERROR]   (package sun.nio.ch is declared in module java.base, which does not export it to the unnamed module)
[ERROR] /home/marty/work/Chronicle-Core/src/main/java/net/openhft/chronicle/core/tcp/FastJ8SocketChannel.java:6: error: package sun.nio.ch is not visible
[ERROR] import sun.nio.ch.IOStatus;
[ERROR]               ^
[ERROR]   (package sun.nio.ch is declared in module java.base, which does not export it to the unnamed module)
[ERROR] 
[ERROR] Command line was: /home/marty/work/programs/jdk-9-ea/bin/javadoc @options @packages
[ERROR] 
[ERROR] Refer to the generated Javadoc files in '/home/marty/work/Chronicle-Core/target/apidocs' dir.
[ERROR] 
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:

For some reason I'm not able to fix it, that's why I won't send PR.

RobAustin commented 6 years ago

@MartyIX could you raise the java doc issue as a separate issue. You say -"Well, I tried to build CQ with the latest -Core, -Bytes and -Wire and it seems to work on JDK 9. However, I must admit I don't use unicode characters. However, I'm happy it works for me anyway." so I'm going to close the first issue as fixed.

hft-team-city commented 6 years ago

Released in Chronicle-Core-1.16.14 (https://github.com/OpenHFT/Chronicle-Core/releases/chronicle-core-1.16.14), BOM-1.16.125 (https://github.com/OpenHFT/OpenHFT/releases/chronicle-bom-1.16.125)

hft-team-city commented 4 years ago

Released in Chronicle-Core-2.20.102, BOM-2.20.134

wangyum commented 3 years ago

--add-opens=java.base/sun.nio.ch=ALL-UNNAMED

OpenHFT / Chronicle-Core

Java 9 compatibility #15