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 09:25:32 GMT

On Jun 4, 2005, at 12:59 PM, Sven de Marothy wrote:


> 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.
>

Freedom is good!  Software livre!

(I *just* couldn't resist...)


> 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...), 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).


>
> 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.
>

True, except I really hate extending java.lang. :)

And maybe we have more to learn in this area from other  
implementations and newer Java APIs.

>
>
>> 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 not?  Why restrict that freedom for users?


> Why would anyone want to do that? You can't distribute them together.
>

I think that depends upon your definition of "free".  If you mean  
"free" as "allowing unhindered action", then you could.  If you mean  
"free" as in "bound by restrictions on the recipient that prevents  
choice in action", then no, you are right.

Remember, we (at the ASF) don't mind that someone might take our  
software and bundle with proprietary anything.  We think that "the  
market" drives contributions back - it doesn't need to be forced  
through a license.

>
> 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.
>

With input from Sun, IBM, BEA, HP, GNU Classpath and everyone else w/  
experience here, we have a chance of achieving just that.  Sun is a  
welcome and peer participant in this community, and I think they have  
a lot to offer, if they'd just start contributing <hint, hint>.


>
>
>
>> 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.
>

I don't believe we do.  I personally have engineering concerns about  
the interface (distinguished from legal/license or philosophical  
concerns, both of which I left behind when we started this...)

I don't want to fork GNU Classpath, and I want to do everything I can  
to help that community flourish.  That said, I do want to keep the  
door open for others.

>
>> 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.
>

Yes.  I want to improve.  Lets learn from GNU Classpath.

geir


>
> /Sven
>
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org




Mime
View raw message