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

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 >