Hi Tomaz, As part of the preparations for JDK 9, Oracle’s engineers have been analyzing open source projects like yours to understand usage. One area of concern involves identifying compatibility problems, such as reliance on JDK-internal APIs. Our engineers have already prepared guidance on migrating some of the more common usage patterns of JDK-internal APIs to supported public interfaces. The list is on the OpenJDK wiki [0], along with instructions on how to run the jdeps analysis tool yourself . As part of the ongoing development of JDK 9, I would like to encourage migration from JDK-internal APIs towards the supported Java APIs. I have prepared a report for your project wildfly-8.1.0 release based on the jdeps output. The report is attached to this e-mail. For anything where your migration path is unclear, I would appreciate comments on the JDK-internal API usage patterns in the attached jdeps report, (if any) - in particular comments elaborating on the rationale for them - either to me or on this list. Finding suitable replacements for unsupported interfaces is not always straightforward, which is why I am reaching out to you early in the JDK 9 development cycle so you can give feedback about new APIs that may be needed to facilitate this exercise. Thank you in advance for any efforts and feedback helping us make JDK 9 better. Rgds,Rory [0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland <JDeps Report for wildfly-8.1.0.Final.html>_______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Hello, Thanks for collecting feedback on this. Here is my initial response: org.w3c.* - These are false alarms. We bundle xalan, xerces, and woodstox for our JAXP providers so that we get consistent behavior on all JVM vendors and versions. The first two introduce the APIs that the report is complaining about. This is misreported as a JDK internal dep, because the JDK implementation of JAXP happens to be a fork of them, and so introduces those APIs as well. org.relax.* - This is a similar issue. We bundle the sun JAXB impl of a fixed version in order to provide consistent results on all JVMs, the classes it is complaining about are actually introduced by a sub JAXB dep (rngom). com.sun.misc.Unsafe - This class is critical to implementing high-performance concurrent data structures and algorithms (hence it’s usage by java.util.concurrent). Our general pattern is to attempt to use it if possible, and fallback to slower, less resilient, yet portable mechanisms. In practice all JVMs now include this class, since all providers prefer to reuse the java.util.concurrent code. If the day comes that java.util.concurrent no longer requires this (or an equivalent class), our primary need for it would be eliminated. sun.reflect.ReflectionFactory - Serialization/Marshalling frameworks need to be able to instantiate classes which do not have public constructors (just like Java Serialization requires). Without this hook, or alternatively usage of unsafe, this is not possible. sun.misc.Cleaner - This is useful in cases where you want to free the memory associated with a direct buffer immediately, preventing degenerate cases of massive native memory consumption, or failures caused by inaccurate limit checking. The main issue is that the garbage collector does not have proper insight into native memory space. and thus may defer freeing what it thinks is a single small reference which in reality is a large block of memory. PhantomReference isn’t a workable alternative. That said, in general we prefer to avoid non-static usage of direct buffers. com.sun.org.apache.xerces.* - This looks like one of our third party deps, XOM, includes some code for Java 5 to workaround bugs and enable secure processing. This code will never actually be ran on WildFly since we require Java 7. sun.misc.Signal/SignalHandler - This dependency has been removed in later versions and uses an alternative strategy. sun.tools.jconsole.Utilities - We have a jconsole gui plugin that is using this. Aren’t all of these jconsole APIs considered unofficial? GSS SPI/API usage - I’d have to research this further as to why jacorb needs these. However, we are looking into switching to a downstream fork of the oracle orb used in the JDK, so this one is likely to vanish as well. -Jason -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

We have jdeps analysis for EAP 6.2.0 GA available since 2013-12-20, see https://bugzilla.redhat.com/show_bug.cgi?id=1045395. I have just added report for EAP 6.4.0 DR1. Could you please check these reports too ? There are items which weren't mentioned in this response - e.g. sun.nio. Thank you. Rostislav ----- Original Message ----- > Hello, > > Thanks for collecting feedback on this. Here is my initial response: > > org.w3c.* - These are false alarms. We bundle xalan, xerces, and woodstox for > our JAXP providers so that we get consistent behavior on all JVM vendors and > versions. The first two introduce the APIs that the report is complaining > about. This is misreported as a JDK internal dep, because the JDK > implementation of JAXP happens to be a fork of them, and so introduces those > APIs as well. > > org.relax.* - This is a similar issue. We bundle the sun JAXB impl of a fixed > version in order to provide consistent results on all JVMs, the classes it > is complaining about are actually introduced by a sub JAXB dep (rngom). > > com.sun.misc.Unsafe - This class is critical to implementing high-performance > concurrent data structures and algorithms (hence it’s usage by > java.util.concurrent). Our general pattern is to attempt to use it if > possible, and fallback to slower, less resilient, yet portable mechanisms. > In practice all JVMs now include this class, since all providers prefer to > reuse the java.util.concurrent code. If the day comes that > java.util.concurrent no longer requires this (or an equivalent class), our > primary need for it would be eliminated. > > sun.reflect.ReflectionFactory - Serialization/Marshalling frameworks need to > be able to instantiate classes which do not have public constructors (just > like Java Serialization requires). Without this hook, or alternatively usage > of unsafe, this is not possible. > > sun.misc.Cleaner - This is useful in cases where you want to free the memory > associated with a direct buffer immediately, preventing degenerate cases of > massive native memory consumption, or failures caused by inaccurate limit > checking. The main issue is that the garbage collector does not have proper > insight into native memory space. and thus may defer freeing what it thinks > is a single small reference which in reality is a large block of memory. > PhantomReference isn’t a workable alternative. That said, in general we > prefer to avoid non-static usage of direct buffers. > > com.sun.org.apache.xerces.* - This looks like one of our third party deps, > XOM, includes some code for Java 5 to workaround bugs and enable secure > processing. This code will never actually be ran on WildFly since we require > Java 7. > > sun.misc.Signal/SignalHandler - This dependency has been removed in later > versions and uses an alternative strategy. > > sun.tools.jconsole.Utilities - We have a jconsole gui plugin that is using > this. Aren’t all of these jconsole APIs considered unofficial? > > GSS SPI/API usage - I’d have to research this further as to why jacorb needs > these. However, we are looking into switching to a downstream fork of the > oracle orb used in the JDK, so this one is likely to vanish as well. > > -Jason > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

Has Oracle run the tool on apache's CXF project? ----- Original Message ----- > From: "Rory O'Donnell Oracle, Dublin Ireland" <rory.odonnell(a)oracle.com&gt; > To: "Tomaž Cerar" <tomaz.cerar(a)gmail.com&gt; > Cc: "Norman Maurer" <norman.maurer(a)googlemail.com&gt;, "Balchandra Vaidya" <Balchandra.Vaidya(a)oracle.com&gt;, > wildfly-dev(a)lists.jboss.org, "Dalibor Topic" <dalibor.topic(a)oracle.com&gt; > Sent: Thursday, September 11, 2014 10:33:44 AM > Subject: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs > > Hi Tomaz, > > As part of the preparations for JDK 9, Oracle’s engineers have been > analyzing open source projects like yours to understand usage. > One area of concern involves identifying compatibility problems, such as > reliance on JDK-internal APIs. > > Our engineers have already prepared guidance on migrating some of the > more common usage patterns of JDK-internal APIs to supported public > interfaces. The list is on the OpenJDK wiki [0], along with instructions > on how to run the jdeps analysis tool yourself . > > As part of the ongoing development of JDK 9, I would like to encourage > migration from JDK-internal APIs towards the supported Java APIs. I have > prepared a report for your project wildfly-8.1.0 release based on the > jdeps output. > > The report is attached to this e-mail. > > For anything where your migration path is unclear, I would appreciate > comments on the JDK-internal API usage patterns in the attached jdeps > report, (if any) - in particular comments elaborating on the rationale > for them - either to me or on this list. > > Finding suitable replacements for unsupported interfaces is not always > straightforward, which is why I am reaching out to you early in the JDK > 9 development cycle so you can give feedback about new APIs that may be > needed to facilitate this exercise. > > Thank you in advance for any efforts and feedback helping us make JDK 9 > better. > > Rgds,Rory > > [0] > https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev