harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sven de Marothy <s...@physto.se>
Subject Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Date Sat, 04 Jun 2005 15:59:18 GMT
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


Mime
View raw message