(Moving discussion of this to arch_at_glassfish.)
tmueller_at_dev.java.net wrote on 10/20/10 02:52 PM:
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=2888
>
>
>
> User tmueller changed the following:
>
> What |Old value |New value
> ================================================================================
> Summary|Try to use standard JDK cl|Try to use standard JDK cl
> |asses only... |asses only
> --------------------------------------------------------------------------------
> Target milestone|3.1 |3.2
> --------------------------------------------------------------------------------
>
>
>
>
> ------- Additional comments from tmueller_at_dev.java.net Wed Oct 20 21:52:07 +0000 2010 -------
> Here is an analysis of the Sun proprietary classes that are used in GlassFish,
> with attention to why they are used, what could possibly replace them, whether
> they should be requested to be part of JDK 7, etc.
>
> com.sun.org.apache.bcel:
>
> All of these classes are used in one module: verifier/verifier-impl, in 3
> classes. One option might be to import the Apache BCEL project code rather than
> using the classes from the JDK. See http://jakarta.apache.org/bcel/.
I thought we were abandoning BCEL for ASM in general...
> com.sun.org.apache.xerces.internal.parsers.DOMParser
> This is used in two places. Once for setting the default parser to use when
> parsing deployment descriptors (DeploymentDescriptorFile) and the other in the
> flashlight/framework module. The later case can probabably void using DOMParser
> altogether.
For the former, is it trying to override the default, or is it trying to
make sure no one else who overrides the default effects this code?
> com.sun.org.apache.xml.internal.utils:
> These classes are only used in verifier/verifier-impl. PrefixResolver is used
> by a test case. PrefixResolverDefault is used as the base class for
> XpathPrefixResolver.
Could it just copy the class and avoid the dependency?
> com.sun.org.apache.xpath.internal:
> These classes are only used in test cases within verifier/verifier-impl
> (VerifierTest).
It needs to use internal xpath APIs? Isn't there a public xpath API
that's good enough?
> sun.misc.BASE64*
> These classes are used to implement GFBase64Decoder and GFBase64Encoder. The
> code from the JDK could be brought into GlassFish or the BASE64 classes could be
> made available in JDK7. The other uses of these classs are in a test case
> (jbi/security - TestClient.java)
There's an optimized base64 encoder/decoder in JavaMail that we should
just clone.
> sun.misc.Resource, sun.misc.URLClassPath:
> These are used by the persistence/cmp module in the EnhancerClassLoader class
> and in the common/glassfish-ee-api module in the ClassLoaderUtil class.
All this code that depends on interpreting the class path is doomed to break.
> sun.net.www.ParseUtil:
> This class isused by the security/core module within several classes in the
> com.sun.enterprise.security.provider package.
There's only a few public methods here, we should clone them or find a way
to use other public APIs to do the same thing.
> sun.security.action.GetPropertyAction:
> This class is used in verifier/verifier-impl and core/logging in a single call:
> new sun.security.action.GetPropertyAction("line.separator")
Oh come one! They could've written that themselves! Clone it!
> sun.security.pkcs:
> These classes are used in security/core in the JarSigner class.
The public security APIs aren't sufficient?
> sun.security.provider:
> These classes are used in security/core within the
> com.sun.enterprise.security.provider package and in
> security/inmemory.jacc.provider in the SimplePolicyProvider class.
If they're parsing policy files, that's something the JDK should expose.
> sun.security.tools.KeyTool:
> This class is used in security/core in the KeyTool class.
That could probably be cloned/replaced.
> sun.security.util.
> These classes are used in various places within the security module. The Der
> classes could be made available in JDK7 as DER is a standard encoding scheme.
What else does it use?
> sun.security.x509:
> These classes are used in the security/ejb.security, security/webintegration,
> and security/core modules. X509 libraries could be made available in JDK7.
We already have javax.security.cert.X509Certificate.
> In summary, the vast majority of Sun proprietary modules are used in the
> verifier/verifier-impl and security modules.
>
> Candidates for requests for including in JDK7 are:
> - BASE64 encoding/decoding
> - DER library
> - x509 library
Yup.
Did you come up with this list by examining all the GlassFish binaries?
Or did you only look at the code in the main GlassFish workspace?
I suspect the latter. I expect there's lots more references in other modules.