Please see online for a few comments.
On Oct 20, 2010, at 5:38 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> (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?
The latter. It sets the parser to DOMParser, parses the document, and then restores the previous value.
>
>> 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?
No
> Or did you only look at the code in the main GlassFish workspace?
Yes. Actually the list came from the GlassFish build output.
> I suspect the latter. I expect there's lots more references in other modules.
Agreed.
Tom