Message-ID: <1127937554.971.1490632341077.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_970_406200192.1490632341076" ------=_Part_970_406200192.1490632341076 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
With JDK 9 development= a> underway in the OpenJDK Community, and based on our experiences with ope= n source projects testing against JDK 9 Early Access builds in the Quality Outreach effort, it seem= s like a good idea to compile the accumulated wisdom to make it easier for = new projects to start testing against JDK 9.
JDK 9 has not been released yet. That mea= ns the tips and suggestions accumulated here should not be taken as the fin= al word on how to adjust your code for JDK 9 as some things may (and probab= ly will) change as the set of JEPs targeted for JDK 9 changes. If in doubt,= ask - preferably on the adoption-discuss mailing list.
This page does not provi= de a comprehensive list of planned or targeted JDK 9 features. For an up to= date list of JEPs targeted for JDK 9, please consult the JDK 9 Project page.
Before you get started testing your code = against JDK 9, there are a few little things to consider.
You can build JDK 9 yourself by following= the build instructions = to build the OpenJDK source code in the jdk9/jdk9 forest. Please check the = list of supported = build platforms to verify that your build platform is supported before you = attempt building JDK 9 from source yourself.
JDK 9 Early Access builds may also be pro= vided by third parties. Oracle publishes regular JDK 9 builds at http://jdk9= .java.net, for example. In the same location, Oracle also publishes reg= ular JDK 9 builds based on the latest Project Jigsaw source code at https://jdk9.java.net/jigsaw/.
If your application's startup script laun= ches the JDK 9 JVM with an unrecognized VM option, it will exit and let you= know that it couldn't create a VM because of that unrecognized VM option. = Some of the VM flags that were deprecated in JDK 8, have been removed in JD= K 9.
In JDK 8 a new Java Dependency Analysis Tool (jdeps) was= added to help developers understand the static dependencies of their appli= cations and libraries. It can help you find dependencies on any internal, u= nsupported or private APIs that your application or its libraries use. A pr= ogram using such APIs is not guaranteed to work in future versions of JDK 9= or even the same platform. For more information, please see this document.
A jdeps plugin for Apache Maven exists= .
For best results, please make sure to run= jdeps from the most recent JDK 8 update release or JDK 9 Early Access buil= d.
Third-party libraries that encounter issu= es on JDK 9 may have had those issues fixed meanwhile as their developers b= egun to test with JDK 9 and address problems found. If you encounter issues= with third party libraries, please check if there is a newer version that = addresses them, and update your code to depend on the newer version.
For example, if your application uses Eclipse RCP 4.4 or below, it may exit wi= th an error message on JDK 9:
java.lang.NoClassDefFoundError: org/w= 3c/dom/stylesheets/StyleSheet
Eclipse RCP 4.5 contains a fix for that issue.
In order to use
javac to cro=
ss-compile to an older release of the platform it is not sufficient to just=
-target options to the older=
value; the bootclasspath must =
also be set to correspond to the older release too. Setting the bootclasspa=
th is sometimes forgotten, potentially leading to obscure errors at runtime.
In JDK 9, the new
javac addresses both of these shortcomings. Now only a =
single flag (
-release) needs to be set to cross compile compar=
ed to three flags (
-source, -target, -bootclasspath) and the n=
eeded information is included in the JDK.
In general, it's simpler to start by buil= ding your code in your familiar build environment, and test it by running i= t on JDK 9, than to start by building it on JDK 9. The tools and libraries = used in your build process might themselves not yet have been tested with J= DK 9 by their developers.
Some of the changes targeted for JDK 9 ma= y affect code that relies on default, deprecated, removed, unsupported, int= ernal or unspecified functionality. The list below has been compiled from t= he list of JEPs targeted for JDK 9 and other resources. It is not an exhaus= tive list of changes - there may be other changes you run into that have no= t been listed here.
Where available, the list provides links = to further resources, like JEPs, mailing list threads or JBS issues.
JEP 249 may affect code co=
nnecting to TLS servers that cannot accept the
status_request_v2 TLS extensions. It implements OCSP stapling via the TLS Certificate Stat=
us Request extension (section 8 of RFC 6066) and the Multi=
ple Certificate Status Request Extension (RFC 6961). The=
OCSP stapling feature will be enabled by default in the JDK with this impl=
JEP 238 may affect co=
de implementing runtimes with class loaders using
ZipFile to load classes, instead of using the URL =
class loader or a custom class loader leveraging
JarFile to obtain platform-specific class files. &n=
bsp;Such code will not be multi-release JAR file aware.
JEP 236 may affect code th=
at uses internal classes in the
ernal.ir package and its sub-packages.
JDK-8148651 may affect code that needs to process class files. Anyone writing tools a= nd libraries for use on JDK 9 that process class files should update their code to handle the n= ew version number. Code using such tools and libraries should be updated to= a version that supports v53 class files.
JEP 253 may affect code th=
at uses internal classes in the
package and its sub-packages.
JEP 245 may affect code th= at passes invalid flag arguments to the JVM. It validates the arguments to = all JVM command-line flags so as to avoid crashes, and ensured that appropr= iate error messages are displayed when they are invalid.
JEP 268 may affect code&nb= sp;using the existing internal catalog implementation. Existing libraries o= r applications that use the internal API will need to migrate to the new AP= I in order to take advantage of the new features.
JEP 272 may aff=
ect code that uses internal classes in the
apple & com.apple packages and their sub-pack=
ages. It is not intended to provide direct replacements for all =
of the internal OS X APIs present in JDK 8. Existing libr=
aries or applications that use the internal API will need to migrate to the=
new API. Specifically, the JEP will not provide a replacement f=
JDK-6260652 may affect code that relies on the Arrays.asList(x).toArray() implementat= ion to return a clone of the backing array, which might be a String, for = example, instead of returning an Object, as specified.
JEP 229 may aff= ect code that uses keystores. It changes the default keystore ty= pe from JKS to PKCS12. By default, new keystores will be created in the PKC= S12 keystore format. Existing keystores will not change and keystore applic= ations can continue to explicitly specify the keystore type they require.= span>
JEP 288 may affect
code that uses X.509 certificate chains with SHA-1 based signatures.=
JEP 283 = may affect graphical applicat= ions on Linux. In = cases where GTK 3 is required for interoperability, and this requirement ca= n be detected sufficiently early, GTK 3 will be enabled automatically.
JEP 260 = may affect code that uses JDK internal APIs. It makes most of the JDK's internal APIs inaccessible by default= , leaving a few critical, widely-used internal APIs accessible, until suppo= rted replacements exist for all or most of their functionality.
= In addition, due to changes necessary to implement this feature, the stack trace of reflective calls will appe= ar somewhat different. Any c= ode analysing, or filtering, based on the stack trace element's class name = should be updated appropriately, to handle this.
JEP 258 may affect code th= at uses the font-layout engine. It replaces the existing ICU OpenType font-layout engine with H= arfBuzz.There may be some minor rendering differences between the lib= raries, as a result of different implementations and a use of more up-to-da= te OpenType specifications.
JEP 280 may affect code th=
at used to instrument the
chains generated by
javac, such =
as byte code manipulation/weaver tools.
JEP 248 may affect code th= at does not explicitly specify the Garbage Collector to use. It makes the low-pause colle= ctor G1 the default garbage collector on 32- and 64-bit server = configurations.The resource usage of G1 is different from Parallel GC= , which is currently the default.
When resource usage overhead needs to be minimized a co= llector other than G1 should be used, and after this change the alternate c= ollector will have to be specified explicitly.
JEP 265 may affect code us= ing the Java 2D graphics rasterizer. This JEP updatse Java 2D to use the Marlin Renderer as the= default graphics rasterizer.
JEP 220 may affect code th= at relies on the removed endorsed-standards override mechanism, the removed= extension mechanism, and the existence of rt.jar and tools.jar files as we= ll as the old directory layout of files in the JDK & JRE installation i= mage.
JEP 223 may affect code th= at relies on the old version string scheme to distinguish major, minor, and= security-update releases.
JEP 271 may change the GC = log message format, without necessarily reproducing all log entries in the = new logging format or ensuring that current GC log parsers work without cha= nge on the new GC logs.
JEP 158 may change log mes= sage formats and possibly the meaning of some JVM options.
JEP 252 may affect code th= at uses locale-sensitive services such as date, time, and number formatting= which may behave differently for locales not supported in JDK 8.
JEP 226 may affect code th=
at loads property files. It defines a means for applications to speci=
fy property files encoded in UTF-8, and extends the
ResourceBundle API to load them by defau=
JDK-8143404 may affect code that relies on the removed AppleScript engine.
JEP 214 may affect code th= at relies on the removed GC combinations.
Users who are using any of the flags that= are being removed will have to update their JVM-startup command lines. If = they are moving from JDK 8 to JDK 9 then they will already have seen warnin= g messages and thus should not be surprised. For a detailed list of the fla= gs and flag combinations that have stopped working in JDK 9, please consult= the JEP text.
JDK-8066750 may affect code that relies on the removed HTTP Proxy implementation= in RMI.
JEP 231 may affect code th= at relies on the removed ability to request, at JRE launch time, a version = of the JRE that is not the JRE being launched.
JDK-6512052 may affect code that relies on the removed java-rmi.exe launch= er.
JEP 240 may affect code th=
at relies on the removed
hprof agent lib=
rary as part of the JDK.
JEP 241 may affect code th= at relies on the removed experimental, unsupported, and out-of-date jh= at tool.
JDK-8037739 may affect code that uses types from java.awt.peer and
All methods that refer to types defined i= n the java.awt.peer and java.awt.dnd.peer= packages (the "peer types") will be removed from the Java API in Java SE 9. Applicat= ion code which calls any such method which accepts or returns a type define= d in these packages will no longer link. This is a BINARY = incompatible change.
JDK-8029806 may affect code that uses the Packer/Unpacker addPropertyChangeLi=
stener and removePropertyChangeListener method
JDK-8029805 may affect code that uses the LogManager addPropertyChangeListene= r and removePropertyChangeListener method= s, which were deprecated in JDK 8, and removed in JDK 9.
JDK-8029904 may affect code that uses the com.sun.security.auth.callback.Dial= ogCallbackHandler, which was deprecated in JDK 8, and removed in J= DK 9.
JDK-7067728 may affect code that relies on the removed stopThread RuntimePermiss= ion from the default java.policy.
JDK-8134808 may affect code that relies on support for serialized applets.
JEP 217 may affect source =
code that uses annotations due to the refactoring of the
javac annotation pipeline, which should not be externally =
noticeable except where bugs were fixed and correctness improved.
JEP 217 may aff= ect source code that uses the applet API. The deprecation annotations will cause deprecation warnings to be em= itted by the Java compiler for all code that uses this API. If warnings are= treated as errors, they will result in build failure.
JEP 277 may affect so=
urce code that uses a deprecated Java SE API. Several Java SE APIs will have a
annotation added, updated, or remo=
ved. Deprecating APIs will increase=
the number of mandatory warnings that projects encounter when building aga=
inst newer versions of Java SE. For more information abo=
ut these planned changes, please consult the JEP text.
JEP 224 may affect source =
code with Javadoc comments since the
/code> feature of
javadoc will be modifi=
ed to validate input comments based upon the requested markup.
JEP 213 may affect so= urce code that uses underscore ("_") as an identifier. Its use ge= nerated a warning as of Java SE 8, and has been turned into an error in JDK= 9.
JEP 275 may aff=
ect code that uses the
javapackager tool. The packager will only create applications that use the=
JDK 9 runtime.
JEP 261 may aff=
ect source code that is not compiled with the
ler using the
ease options to select the use of legacy mode. =
The stack traces generated for exceptions at run time have been extended to=
include, when present, the names and version strings of relevant modules. =
The detail strings of exceptions such as
code class=3D"prettyprint">IllegalAccessException, and
Error have also been updated=
to include module information. Any=
code analysing, or filtering, based on the stack trace element's detail st=
rings should be updated appropriately, to handle this.=
dition, this feature may affect code that assumes that the application clas=
s loader or the extension class loader&n=
bsp;is an instance of
ssLoader, rather than of an inter=
feature may also affect code that attempts to set or read the bootclasspath=
-Xbootclasspath or the -
lasspath/p options, or the removed JDK-specific system property
Changes due primarily to the introduction of t= he Java Platform Module System = ;may affect code which
public= modifier to an API element guarantees that the element will be everywhere a= ccessible, or
Class::getResource*&n= bsp;methods to read JDK-internal resources, or
java.lang.reflect.AccessibleObject::setAccessiblemethod to gain access to members of packages= that are not exported by their defining modules, or= span>
Existing code that invokes
ClassLoader::getSystemClassLoader and blindly casts the result to
URLClassLoader, or =
does the same thing with the parent of that class loader, might not work co=
Existing= custom class loaders that delegate directly to the bootstrap class loader = might not work correctly; they should be updated to delegate to the extensi= on class loader.
transform method declared in the
java.lang.instrument.ClassFileTransformer interface is now a default method.
code that scans for
resource files previously found in&n=
rt.jar and other internal artifacts which are not present in the=
corresponding system modules files might not work correctly.=
specific system property
ing can be set on the comman=
d line via the
-D option, as before, but it will only work when=
it specifies a charset defined in the base module. Existing launch scripts=
that specify other charsets might not work correctly.
JDK-8011044 may affect source code that uses javac -source or -target options be= low 6/1.6 to compile.
JEP 221 may affect co= de that uses the Doclet API. It replaces the Doclet API with a simpler design that leve= rages newer alternative APIs with improved functionality, and updates the s= tandard doclet to use it.
If you would like to provide feedback on = JDK 9, but don't know yet where to start, please begin by subscribing to th= e adoption-discuss mailing lis= t, and initiating a conversation on that mailing list about your particular= item of feedback. Depending on the content, you may be asked to file an is= sue in in JBS, to provide further information or to continue the conversati= on on a specific OpenJDK Community mailing list more suitable for further d= iscussion.
JEP 261 implements t= he Java Platform Module System, as specified by JSR 376, together with = related JDK-specific changes and enhancements. As announced on the jigsaw-dev mailing list, experience reports from= early testers and adopters are especially welcome. Please try out the EA builds and let the developers know what you learn o= n the jigsaw-dev mailing list.
There may be other changes worth consider= ing to add to this page. If you have suggestions for items to add to this l= ist, please send an e-mail to the adoption-discuss mailing list.