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

[Jason Greene]

Ah yes I forgot to address sun.nio, which is used in the codemodel project contained in both WildFly and EAP.

This project generates source code and is a dependency of the JAXB RI, which we bundle (see earlier response for why). Looking at the project, the sun.nio classes are only directly used when the MS1252 encoder is used, and according to the comments in the source was done to workaround a bug on JDK 1.4.2. 

This workaround appears to have been removed in the latest trunk of the repo, but AFAICT there is not a release available with this fix:
https://java.net/projects/codemodel/sources/svn/revision/333


On Sep 16, 2014, at 6:34 AM, Rostislav Svoboda <rsvoboda at redhat.com> wrote:

> 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
>> 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat