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

[Rostislav Svoboda]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>