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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
