harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-2130) DaCapo antlr fails on drlvm
Date Fri, 08 Dec 2006 15:55:02 GMT
There is enough info in the manifests to do this classloader trickery at
runtime -- by explicitly listing what we export/import from a module we
can hide purely implementation-specific packages.

The remaining pieces are to (1) define a manifest that exports only the
JSE-defined packages (to remove the inter-module dependencies), (2)
implement the classloader framework to only expose the packages they see
in the manifests.  This is something that we are actively pursuing, but
it's not in a fit state to share just yet.

Regards,
Tim

Robin Garner wrote:
> Nathan Beyer wrote:
>> On 12/7/06, Stefano Mazzocchi <stefano@apache.org> wrote:
> [snip]
>>>
>>> I'm sorry, but this argument is defective.
>>>
>>> Sun does ship xerces and xalan bootclasspathed and to avoid
>>> interference, they moved the packages.
>>
>> Sun may do this, but IBM doesn't. I don't know about Java 5 distros,
>> but with IBM Java 1.4.2 JREs, the xerces and xalan classes weren't
>> changed and do cause interference.
>>
>> -Nathan
> 
> IBM's J9 distro does the same thing.  OTOH I don't think it's a good
> enough excuse for Harmony to do likewise.  If DRLVM can come up with a
> better solution like Geir's 'inner classloader', I think this would be a
> Good Thing, and maybe IBM will eventually see the light.
> 
>>>
>>> If we provide something that our own internal machinery depends on, we
>>> either shield it and avoids it showing in the userland classloading
>>> area, or we change the package and make it 'our own' stuff.
>>>
>>> Asking any program to adapt to our own behavior (whatever that is and
>>> for whatever technical reason) is wrong and against basic
>>> interoperability principles.
>>>
>>> *any* program that runs on RI should run, unmodified, on harmony.
>>> Anything else is a bug and needs to be fixed, somehow.
>>>
>>> So, we can be clever and write a classloader that understands who is
>>> calling and provides 'virtual' classloading zones (but I'm not sure this
>>> can be made compatible with the java spec) or we bytecode-rewire the
>>> packages of the libraries we bootclasspath.
>>>
>>> Asking others to change is not an option.
>>>
>>> -- 
>>> Stefano.
>>>
>>>
> 
> 

Mime
View raw message