Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Java 9 Readiness"

(JNA and HttpClient)
 
(2 intermediate revisions by 2 users not shown)
Line 34: Line 34:
 
=== Reflection hacks ===
 
=== Reflection hacks ===
  
Unfortunately jdeps does not detect access to internals made via reflection. You have to check your code for such cases and fix them.
+
Unfortunately jdeps does not detect access to internals made via reflection, so there's no static detection, but you may run Eclipse on a Java 9 VM, with a vm argument <code>--illegal-access=debug</code> which will print stack traces of all locations performing illegal reflective access at runtime.
  
 
=== Java 9 Readiness ===
 
=== Java 9 Readiness ===
Line 90: Line 90:
 
| Carsten Reckord
 
| Carsten Reckord
 
| Yes
 
| Yes
 +
| n/a
 +
|-
 +
! Eclipse Scout SDK
 +
| Matthias Zimmermann
 +
| Yes @ Oxygen.1a
 
| n/a
 
| n/a
 
|-
 
|-
Line 144: Line 149:
 
| Yes - uses com.sun.jna.platform, but not the problematic WindowUtils class
 
| Yes - uses com.sun.jna.platform, but not the problematic WindowUtils class
 
| n/a
 
| n/a
|-
 
 
|-
 
|-
 
! .
 
! .
 
| .
 
| .
 
| .
 
| .
 +
| .
 +
|-
 
|}
 
|}

Latest revision as of 11:14, 29 September 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.

Configure Eclipse for Java 9

See Configure Eclipse for Java 9 for details on configuration.

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:

NOTE:

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.

Reflection hacks

Unfortunately jdeps does not detect access to internals made via reflection, so there's no static detection, but you may run Eclipse on a Java 9 VM, with a vm argument --illegal-access=debug which will print stack traces of all locations performing illegal reflective access at runtime.

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 might not 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) Yes (will work with Java 9 source)
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.
Eclipse Marketplace Client (MPC) Carsten Reckord Yes n/a
Eclipse Scout SDK Matthias Zimmermann Yes @ Oxygen.1a n/a

Known state of Orbit Bundles.

Bundle Version Runs on Java 9 Supports Java 9
com.google.guava 15.0.0 Yes. All uses of sun.misc.Unsafe have a safe fallback. n/a
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

org.apache.felix.gogo.runtime 0.10.0 bug 514939 n/a
com.sun.jna 4.1.0 Yes n/a
com.sun.jna.platform 4.1.0 Mostly - WindowUtils.setWindowAlpha(Window, float) on Mac uses java.awt.Component.getPeer(), which has been removed in Java 9. Fixed in JNA 5, see https://github.com/java-native-access/jna/pull/807 n/a
org.apache.httpcomponents.httpcore 4.4.6 Yes n/a
org.apache.httpcomponents.httpclient 4.5.2 Yes n/a
org.apache.httpcomponents.httpclient.win 4.5.2 Yes - uses com.sun.jna.platform, but not the problematic WindowUtils class n/a
. . . .

Back to the top