On Fri, 2005-06-03 at 14:01 -0500, Dan Lydick wrote: > Naw, but have you ever looked into how to design and > construct a JVM? The fundamental classes like java.lang > can typically have implementation-specific requirements, > so I am trying to focus on isolating these items from > the rest of the library.
Right, this is a concern for all. GNU Classpath does this through its VM inteface classes (e.g. VMObject, VMClass, VMClassLoader) I don't see why this isn't good enough. It's certainly seems good enough for the existing VMs which use Classpath. > What I mean is implementation policy on how a class > library does its work. If the Harmony implementation > can keep from being forced to do things somebody else's > way, then Harmony may use libraries from vendors such > as these without concern of being forced into their > JVM or other class library implementation. Basically > this means commanding a central core of packages via > the bootstrap class loader and letting a library > supplier do the rest. Well, again, I can't see what's so bad about Classpath's way of doing this. And I can't see why you would want this freedom. AFAIK there are no other class libraries out there which you'll legally be able to distribute with Harmony. So why create flexibility when there aren't options? I mean, you can at least just use the Classpath interface for the time being, and use this strategy once there is some reason to. > The underlying idea here is to make as few changes > as possible to as little of the java.*, especially > java.lang.*, or other core library packages in order > to give the Harmony JVM runtime environment the > greatest flexibility for using libraries. Heck, > if it's done right, you might be able to use Sun's > or IBM's java.* library implementation! Why would you want to have a Free VM which can use non-free libraries? Why would anyone want to do that? You can't distribute them together. Really, if you want a real solution here, it's to get Sun to publish a spec for the VM-Classlib interface which we can all use, and this problem will go away by itself. > At least this is my idea. I don't know if this is > actually possible because it is heavily dependent > on the library implementation from vendor X, Y, and > Z. I do like the idea of using/reusing GNU Classpath > where it shines and of Harmony either contributing to > it or extending it where some improvements are > appropriate or writing complete replacements where > the implementation is too weak for our use. At least > this is what I have gathered from others in the > discussion on the list on this subject. The way I've intepreted most of the posts here, is that most were decidedly against forking Classpath. What makes you think that there are Harmony-specific improvements to be made which wouldn't be usable by others? I feel like there's a lot of uncertainty being cast on GNU Classpath here for no reason. A lot of folks seem to have the impression we've got different goals and/or priorities. We do not. > This is the extent of what I mean. I don't want to > re-invent any wheels that don't need it. Ok. Well I still don't understand. Classpath has a VM-classlib interface which is being used by a whole bunch of VMs. If that inteface isn't good enough for Harmony (and given that the Harmony JVM does not exist, it seems premature to decide that it isn't), then I'd suggest improving it instead of reimplementing a bunch of stuff. /Sven
