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 do think that it is a shame that Java has not incorporated versioning with classloading, or has designed a more compartmentalized classloading architecture. 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) -- Stefano. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
