harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
Subject Re: [arch] VM Interface
Date Tue, 07 Jun 2005 19:21:18 GMT

On Jun 7, 2005, at 9:49 AM, Archie Cobbs wrote:

> Geir Magnusson Jr. wrote:
>>>> I assume that if the Harmony JVM gets half as good as is hoped   
>>>> there will be companys who want to adopt the JVM but continue  
>>>> to  use Suns class library so that differences in libraries  
>>>> don't hurt  their customers.
>>> If that is a goal of Harmony then we've just made things a lot  
>>> harder.
>>> First of all, Sun's class library <-> VM interface is proprietary  
>>> and
>>> unpublished. How would people become experts in it without studying
>>> the Sun source code, with all the potential legal problems that   
>>> entails?
>> Because it's possible that Sun finds this aspect of Harmony  
>> valuable  overall, and contributes information to help shape this.
> I highly doubt that will happen (just my opinion though).
>>> Secondly, you can no longer use Classpath as is, so Harmony will  
>>> have
>>> to create a new fork of the Classpath code. Lots of work, zero  
>>> forward
>>> progress.
>> No, we won't fork GNU Classpath.  I don't understand why you  
>> believe  we have to do this.
> Well, the alternative is to convince the Classpath developers to  
> completely
> rewrite the existing API to match whatever Sun currently does  
> (which is
> unknown, and would probably taint them), and also convince all the  
> current
> VM implementers to change their implementations. As a Classpath  
> developer
> and VM implementer, I even more highly doubt that.

I don't think anyone suggested that we should match what Sun does.   
Maybe get some insight into what they needed to do for J2SE 1.5  
(since they have done it..), and what they learned building one of  
the finest VMs out there.  But just do what they do?  No.

>>> Thirdly, what's to stop Sun from changing things around every  
>>> release?
>>> Their API is not standardized in any way. It involves "sun.*"   
>>> classes, etc.
>> Nothing.
> So you have a moving, undocumented API to support. Sounds fun :-)

We don't have to support it.  The question is "what stops Sun?" the  
answer is "nothing".  But we don't have to support it.

>>> On the other hand, if down the road the various interested parties
>>> got together and said, "Let's all agree on a common class library/ 
>>> JVM
>>> API" then certainly Harmony should be involved and supportive.  
>>> However
>>> somehow to me that seems about as likely as Toyota, Ford, and GM all
>>> agreeing to standardize the connection between engines and  
>>> gearboxes.
>> That agreement is one of the things we're trying to do here,   
>> remember.  I don't know if the analogy is right though (although   
>> there is a bit of standardization in the auto industry).  Maybe  
>> the  computer industry would be a better example?  :)
> I think it would be great to get there someday. The thing to do would
> be to create a JCP project to standardize the Class/VM API.
> However, the fact that this is a nice idea doesn't seem to have any
> impact on the current situation for Harmony.
> Are you saying Harmony should wait for such a JCP to be proposed,
> accepted, and standardized? That will take years.

Come on -  I think I [jokingly] suggested we take what *we* develop  
and bring to the JCP, not wait for it.

> Are you saying Harmony should adopt Sun's current, undocumented,
> proprietary, and subject-to-change-at-any-time API? That seems like
> a really bad idea for a large number of reasons.

I'm starting to wonder if you read what I actually wrote.  I  
suggested we try to figure out what Sun did to learn from them.

> Even the idea that there will be any interest in combining Sun's  
> classes
> with a Harmony VM is suspect IMHO as well (would that even be legal?).

Why not?  If I had a license from Sun to do so?

> So in summary: I just don't get it.

I suppose not - I thought the issue is really simple, and I'm sorry  
it's gotten a bit off track.

We started with the idea that in part, we should look at  
modularization of a VM platform.  One of the connection points is the  
VM<->Class library interface, and since we have something to start  
with - the GNU Classpath interface - I suggested we start there, and  
see what additional information we can gather from those that have  
done more advanced and complete implementations (Sun, IBM, BEA, HP,  
etc) and with those considerations, produce an interface that works  
for where we are targeting to go.

No one is suggesting we standardize on Sun's interface, wait until  
the JCP does something about this, or bundle our (or anyone else's)  
stuff w/ Suns libraries.  (As for the latter, it would be nice if it  
was an option for those that choose to go that route... Freedom is  
good :)


Geir Magnusson Jr                                  +1-203-665-6437

View raw message