Difference between revisions of "Java 9 Readiness"
(Merge edit by Marvin.mueller.bredex.de)
|Line 121:||Line 121:|
Known state of Orbit Bundles.
Known state of Orbit Bundles.
Revision as of 11:05, 29 March 2017
This wiki page explains how projects can check whether they are ready for Java 9 and documents the state for each release train project. The page also indicates which projects will provide new support for Java 9, e.g. Eclipse JDT. Those projects are expected to contribute to what we will offer once Java 9 goes GA. Note that at this point, the Planning Council did not yet decide how to do that.
The biggest feature in Java 9 is the Java Platform Module System, a.k.a. Jigsaw. With this, access to internal code of the Java runtime will no longer work. The Planning Council requests every release train project to check whether they use internal code from the Java runtime, or whether they use a library (most likely from Orbit), that does so.
Java 9 uses *.jmod to package libraries as modules. The Java 8 version of JDT can't handle modules and so can't recognize a Java 9 JRE/JDK. Unfortunately licensing issues prevent JDT distributing Java 9 support until Java 9 GA. Consequently use of Java 9 prior to GA is not as trivial as one might expect.
There are several things you can do to check the readiness for Java 9.
- 1 Configure Eclipse for Java 9
- 2 Run your tests with Java 9
- 3 Check whether your project or required libraries use internals of the Java VM
- 4 Reflection hacks
- 5 Java 9 Readiness
Configure Eclipse for Java 9
Download Java 9
You need to download and install a Java 9 VM, e.g. from https://jdk9.java.net/.
Configure Eclipse to run on Java 9 VM
Unless you have Java 9 on your system path, you need to specify the use of your Java VM. If you already do this, simply replace it with a Java 9 VM. Otherwise it can easily be done by adding something like:
-vm C:\Program Files\Java\jdk-9\bin\javaw.exe
following the --launcher.appendVmargs line to the eclipse.ini.
Configure Eclipse for Java 9 modules
Since the Eclipse SDK uses types that aren't in the java.base module, you need to add the following vmargs to eclipse.ini:
This step will no longer be necessary with 4.7 M7 and newer, as the launcher will add this by default (bug 493761). Your project might fail to run because you use types that are neither in java.base or java.se.ee, e.g. types from javafx.base. In that case you have to figure out which module(s) you need to add with --add-modules.
- Only works in JDK 8, but not in JDK 9: Run
- In Eclipse with Java 9 Support (BETA) for Oxygen (see below), you can open the type in a JavaSE-9 JRE and perform Show In > Package Explorer. Inside the "JRE System Library" node, the Package Explorer will show the module in which that type resides.
Your eclipse.ini should contain something like:
--launcher.appendVmargs -vm C:\Program Files\Java\jdk-9\bin\javaw.exe -vmargs -Dosgi.requiredJavaVersion=1.8 --add-modules=ALL-SYSTEM
Install Eclipse Java 9 Support (BETA)
This is useful if you have to debug problems, e.g. when it fails to run your project.
This is essential if you want to run JUnit tests in the Eclipse IDE using Java 9.
We recommend to install the support via https://marketplace.eclipse.org/content/java-9-support-beta-oxygen/ because it is crucial that the Eclipse install, the Java 9 VM and the patch match. If you are not using an EPP with a pre-installed Marketplace Client, you must install it first (from the General Purpose Tools category of the http://download.eclipse.org/releases/oxygen P2 repo).
Another way to install it is to use Ed's Oomph based installer described here: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14178.html.
Specify a Java 9 JRE
Use Window->Preferences->Java->Install JREs to make your Java 9 VM available within Eclipse.
You may want to associate Java 9 with some Execution Environments to force a rebuild using Java 9.
Run your tests with Java 9
You can do this locally or soon on Hudson. A Java 9 VM will hopefully be available on Hudson soon (bug 513618). To launch tests or self-hosted applications locally from your IDE with a Java 9 JRE, you need to install the Java 9 BETA support to configure an Installed JRE that points at a Java 9 JRE or JDK.
For JUnit (standalone) tests, you should specify a Java 9 execution environment on the JRE launch configuration tab.
For JUnit Plugin tests, you should specify a Java 9 execution environment on the Main launch configuration tab and as noted above, you must add "--add-modules=java.se.ee" to the VM arguments on the Arguments tab..
Check whether your project or required libraries use internals of the Java VM
Since Java 8 there is a tool that allows you to check whether you use internals of the Java VM. It is called
jdeps(.exe). There are two ways you can check your code / repository:
- There is an Apache Maven JDeps Plugin (https://maven.apache.org/plugins/maven-jdeps-plugin/)
- The Eclipse Platform project has created a script (https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/plain/production/reports/jdepsReport.sh) that calls jdeps during the build and generates a report. I suggest to use that approach. Please contact Sravan Lakkimsetti if you have any problems with this script.
1) We made an initial scan of the Oxygen (4.7) M5 release train repository and most of the violations are in third-party code. You have to work with the providers of the libraries to get this fixed or find an alternative approach.
2) https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool lists alternatives that can be used instead of the internal code. You can see in this list that there's not a replacement for every issue, e.g. sun.misc.Unsafe has no replacement and continues to work, at least for now.
Unfortunately jdeps does not detect access to internals made via reflection. You have to check your code for such cases and fix them.
Java 9 Readiness
If a release train project is not listed here, it means it has not been checked yet, and you have to assume it won't run on Java 9. If something does not work, it should be covered by a bug report.
|Project||Contact||Runs on Java 9||Adds Java 9 Support|
|Eclipse Project (Platform, JDT, PDE)||Dani Megert||Yes, but the module java.se.ee needs to be added and we have an open issue with some Platform UI tests due to org.objenesis (bug 508734).||Yes, new code to support Java 9 development, compilation, and debugging will be delivered.|
|Web Tools Platform (WTP)||Carl Anderson||Not yet tested||Yes, new code to support Java 9 facets will be delivered|
|EclEmma||Evgeny Mandrikov||Yes||Yes, ability to measure code coverage by tests that are executed on Java 9 will be delivered.|
|Code Recommenders||Andreas Sewe||Yes @ M7 (bug 513634)||Not planned yet (and blocked by bug 514393 and bug 514394).|
|Automated Error Reporting||Andreas Sewe||Yes||n/a|
|Object Constraint Language (OCL)||Ed Willink||Yes @ M7.||n/a|
|Declarative QVT (QVTd)||Ed Willink||Yes @ M7.||n/a|
|Eclipse for Testers||Marvin Mueller||No / Yes if using "--permit-illegal-access"||Not planned yet.|
Known state of Orbit Bundles.
|Bundle||Version||Runs on Java 9||Supports Java 9|
|org.objectweb.asm||5.2.0||Yes.|| No. The ClassReader throws an IAE for greater than Opcodes.V1_8.
Workaround: in JaCoCo - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L101 This is safe, because Java 9 does not introduce any new instructions. Version can be restored after bytecode generation/modification - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L112