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: [classlib] Using Yoko as CORBA for Harmony
Date Thu, 27 Jul 2006 12:29:27 GMT
Stefano Mazzocchi wrote:
> Geir Magnusson Jr wrote:
>   
>> Mikhail Fursov wrote:
>>     
>>> Does it mean that BCEL will be a part of JRE? So we can have problems with
>>> different BCEL versions if two of them is in classpath..
>>>       
>> Heh.  I forgot about that.  I was just thinking about licensing terms.
>>
>> I assume we can simply treat things as local to the boot classlibath if
>> we needed to somehow?
>>     
>
> I don't think BCEL will be the only one we will have a problem with:
> xerces and xalan come to mind.
>
> Sun changed the package names from org.apache.xerces to
> com.sun.apache.xerces to avoid exactly that, they will probably do the
> same with rhino for the next versions of the JVM.
>
> It wouldn't be hard to write a "jar rewriter" that would simply change
> the package name in every class it finds (based on a regular expression
> or something like that).
>
> Another, maybe more elegant solution, would be to create a classloading
> architecture that is sealed, but I don't think the current state of java
> affairs allows for such a thing to be both compliant and solid.
>   

I agree that package renaming is not a great solution, especially since 
you have to do it transitively so have the possibility of numerous 
copies of the same shared prerequisite rewritten to different package 
names (or you have to portray the versioning relationship in those 
package names).

We already have the OSGi metadata for our Harmony modules in the jar 
files on the bootclasspath.  We can use that information at runtime to 
define the visibility of packages within and outside the bootclasspath.
> I do think that it is a shame that Java has not incorporated versioning
> with classloading, or has designed a more compartmentalized classloading
> architecture.
>   

This is very much in the frame at the moment though, with jsr277, 
jsr291, et al working in this area.

> But the problem of having part of our class library depend on classes
> that have the same name of *different* classes that might be running in
> user space is a problem that we have to face because it's going to
> surface in pretty much any important java application (and with
> appservers it gets even worse

Yep, and I'd like to do something more robust than package renaming (as 
you point out).

Regards,
Tim



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message