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] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Date Sun, 05 Jun 2005 17:20:53 GMT

On Jun 5, 2005, at 1:45 PM, Sven de Marothy wrote:

> On Sun, 2005-06-05 at 06:25 -0300, Geir Magnusson Jr. wrote:
>> On Jun 4, 2005, at 12:59 PM, Sven de Marothy wrote:
>>> 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?
>> Are you kidding?  There aren't options *now* (well, that's not really
>> true, is it...),
> Could you elaborate on that? I don't know of any class library
> distributable under the Apache license.

There are other licenses.  Remember, we aren't only concerned about  
ourselves, but what a downstream user of our stuff will want to do.  
We tend to try to protect their freedoms as well.  (See "Ulcer,  
Geir's, re J2EE TCK license")

>> but that doesn't meant that options won't come
>> around in the future.  I think we're still in the very beginning of
>> "managed runtime environments" and generalization w/o penalty is a
>> Good Thing(tm).
> Reimplementing java.lang certainly is a penalty.

I don't understand - I might have misstated something.  Why do you  
think I want to re-implement java.lang?  Any JVM that uses GNU  
Classpath has to implement java.lang parts, right?  All I'm  
suggesting that we move the stuff that's not standard java.lang as  
defined in a spec somewhere off to another package name.

> Again, this is NOT a major issue. *If* or *when* these options become
> available, *that* will be the time to adress this. It is not such a
> major task as folks seem to think here to change the VM-classlib
> interface. Indeed it has been done already for VMs such as JikesRVM.

Why not do it now so we don't have to fix it later, since to do J2SE  
5 we *are* going to have to modify it...

> Reimplementing java.lang is more work.

See above - I think there is a miscommunication here

>> And maybe we have more to learn in this area from other
>> implementations and newer Java APIs.
> I don't like "maybe"s. I like specific problems for which I can devise
> specific solutions.

Me too, and I'm hoping someone who has done this will point out some  
specific problems they needed to solve.

> Maybe Java 1.6 will require VMs to be able to make breakfast;  
> Should we
> start designing a VM-toaster interface, just in case?

As long as you don't put it in java.lang, I'm all for it...  :)

But before we go leaping off to 1.6, how about 1.5?

>>> Why would you want to have a Free VM which can use non-free  
>>> libraries?
>> why not?  Why restrict that freedom for users?
> 1) Because Sun hasn't documented their VM interface.

We don't care, do we?  We can do our own.

> 2) Because people who have Sun's class library already have Sun's VM.
> What would they want with Harmony for?

Ya never know :)

> 3) Because I thought the main idea was a complete VM under the Apache
> license. Not ASL+SCSL.

Remember the modularity goal - we want people to be able to take this  
stuff and plug-n-play with whatever they want.  If for whatever  
reason they wanted to plug in Sun's class library, why would we want  
to prevent that?


Geir Magnusson Jr                                  +1-203-665-6437

View raw message