Re: [wildfly-dev] Analysis of wildfly-8.1.0 dependency on JDK-Internal APIs

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