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: The Classpath VM interface. (Please read)
Date Tue, 07 Jun 2005 13:55:09 GMT
On Tue, 2005-06-07 at 08:15 -0400, Geir Magnusson Jr. wrote:
> On Jun 6, 2005, at 2:29 PM, Sven de Marothy wrote:
> > Sun has not documented how their VM works with rt.jar. Therefore it is
> > not possible to develop a Sun class library-compatible VM in a
> > clean-room fashion.
> Not *now*, but Harmony has the potential to be a long-running, far- 
> reaching project, and our interest from the beginning is to have Sun  
> involved.  So it's not unthinkable to assume that Sun might be  
> interested in participating at some point in the future.

I don't quite see what the one has to do with the other here.

> > 1) GNU Classpath's VM interface doesn't include things necessary for
> > J2SE 5.
> >
> > (My take on it: There is no VM which needs them yet.)
> But you absolutely know we will.

Right. But because no VM needs them yet, nobody around (who's made
themself known) has worked out *exactly* what demands that puts on the
VM interface. And without that detail Harmony can't devise a Java 5 VM
interface any more than GNU Classpath can.

> > 2) GNU Classpath's VM interface uses language protection such as
> > package-privacy to hide the VM classes.
> >
> > (My take on it: Why is that a problem?)
> You are misrepresenting the problem.  it's not that it's language  
> protection, but that you extend java.lang namespace and are hoping  
> that you don't get tromped by the spec at some point in the future.   
> (Nor is it clear that it's good citizenship working in that namespace  
> as well...)

I still don't see the problem. You may always get tromped by the spec in
the future. And as for namespace issues; We're not extending the public
namespace. I don't see the issue. 

And it's not just about the VM interface. In fact, I don't see how its
possible to do a good implementation of the class library *at all*
without adding package-private methods, or classes. (And while I can't
be certain offhand like this, I think there are parts which are simply
*impossible* to implement without adding package-private parts.)

> But just as GNU Classpath thought it wise to keep the door open for  
> multiple VM implementations, we are trying to do the same for mutiple  
> class library implementations.

This is a job for the JCP. If you want a standard interface, get the JCP
to create a spec for one. 

But if you develop your own interface and only GNU Classpath uses it,
it's not keeping the door open. 

(And worse, if GNU Classpath doesn't use it, all you've got is yet
another inofficial interface. And that'll be even worse for


View raw message