10:40 a.m.
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