harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib] Using Yoko as CORBA for Harmony
Date Fri, 28 Jul 2006 22:05:25 GMT


Tim Ellison wrote:
> 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.

Right - that's what I was suggesting, although I wasn't clear, but I
think it requires further information that defines what the
bootclassloader can expose to calls from stuff from off the bootclasspath.

Right now, mx4j shines right through, for example.

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

We should find out what real-world experience they are basing the work
on, and model after that for now, or if it's being invented from
whole-cloth in the EGs, and we can't publicly talk about those
approaches, we go our own way for now...

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

Absolutely.

geir


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