arch@glassfish.java.net

Re: [Issue 2888] [admin] Try to use standard JDK classes only

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Wed, 20 Oct 2010 15:38:38 -0700

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