You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Sven de Marothy <sv...@physto.se> on 2005/06/04 17:59:18 UTC
Re: [arch] How much of java.* and friends does Harmony need to
write. Was: VM/Classlibrary interface
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
Re: [arch] How much of java.* and friends does Harmony need to write.
Was: VM/Classlibrary interface
Posted by Ulrich Kunitz <ku...@deine-taler.de>.
On Sun, 5 Jun 2005, Geir Magnusson Jr. wrote:
> > Also from time to time the VM interface has to be extended for new
> > VMs, which have different needs. This is one reason that the
> > interface isn't yet stable, even for 1.4.
>
> It would be interesting to know why and how it was extended - there's
> something to learn there. I'm also interested in getting some input from the
> commercial VM developers.
The new features in 1.5 varargs, enums, annotations, and generics
required additions to the class file format. More changes appear
to be introduced to improve debugging (type infos about local
variables).
Tom Tromey has already found a link to an updated class file
description:
http://java.sun.com/docs/books/vmspec/2nd-edition/UpdatedClassFileFormat.pdf
Here is a short and probably incomplete overview over the changes:
varargs: ACC_VARARGS, ACC_BRIDGE (?)
enums: ACC_ENUM
annotations: ACC_ANNOTATION
New attributes: EnclosingMethod, Signature (for generics),
LocalVariableTypeTable,
RuntimeVisibleAnnotations,
RuntimeInvisibleAnnotations,
RumtimeVisibleParameterAnnotations,
RumtimeInvisibleParameterAnnotations,
Uli
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Geir" == Geir Magnusson <ge...@apache.org> writes:
>> I still don't understand why you think this.
>> Could you explain what problem might arise?
Geir> Sun adds "java.lang.VMObject" as a public class (ok, farfetched) or
Geir> adds it as a private class (not so farfetched).
Ok, this is the scenario. This I understand.
But what actual problem does this cause?
Tom
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 5, 2005, at 2:05 PM, Tom Tromey wrote:
>>>>>> "Geir" == Geir Magnusson <ge...@apache.org> writes:
>>>>>>
>
> Geir> That's not fair. I told you that *I* think that extending
> java.lang
> Geir> is a *bad idea*.
>
> I still don't understand why you think this.
> Could you explain what problem might arise?
Sun adds "java.lang.VMObject" as a public class (ok, farfetched) or
adds it as a private class (not so farfetched).
>
> Geir> Also, I don't know what the 1.4 and 1.5 Java API requirements
> on the
> Geir> VM are, but given that GNU Classpath isn't there yet, isn't
> it even
> Geir> plausible that may have something to add?
>
> Yeah, the VM interface has to be extended in a few ways for 1.5.
>
> Also from time to time the VM interface has to be extended for new
> VMs, which have different needs. This is one reason that the
> interface isn't yet stable, even for 1.4.
It would be interesting to know why and how it was extended - there's
something to learn there. I'm also interested in getting some input
from the commercial VM developers.
geir
>
> Tom
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Geir" == Geir Magnusson <ge...@apache.org> writes:
Geir> That's not fair. I told you that *I* think that extending java.lang
Geir> is a *bad idea*.
I still don't understand why you think this.
Could you explain what problem might arise?
Geir> Also, I don't know what the 1.4 and 1.5 Java API requirements on the
Geir> VM are, but given that GNU Classpath isn't there yet, isn't it even
Geir> plausible that may have something to add?
Yeah, the VM interface has to be extended in a few ways for 1.5.
Also from time to time the VM interface has to be extended for new
VMs, which have different needs. This is one reason that the
interface isn't yet stable, even for 1.4.
Tom
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Geir" == Geir Magnusson <ge...@apache.org> writes:
>> Yes, 1.5 *will* add new requirements to the VM interface. But the
>> Classpath VM interface isn't some immutable static thing either.
>> All I'm saying here is: how about crossing that bridge when you get
>> there, instead of deciding out of hand that it isn't good enough?
Geir> Guess which version of J2SE we want to do...
So far nobody has systematically looked at all the VM layer changes
needed for 1.5.
However, I have looked at a few. The ones I've looked at are mostly
related to Class or reflection; we need to add some more methods to
VMClass and friends to account for the new data that is available. We
also needed VMClass.cast(), a change to VMSystem for the new getenv,
and a change to VMProcess for ProcessBuilder.
As far as I know we won't need any major overhauls, just additions
here and there. But if someone wanted to go through all the new bits
and check this, that would be helpful. Better yet, actually go write
the new bits, there is plenty of 1.5 stuff still to be done.
Tom
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 5, 2005, at 1:30 PM, Sven de Marothy wrote:
> On Sun, 2005-06-05 at 06:21 -0300, Geir Magnusson Jr. wrote:
>
>
>> That's not fair. I told you that *I* think that extending java.lang
>> is a *bad idea*. You many not agree, but that's not the same is
>> NIH. That doesn't mean that java.lang.VMObject can't be move to
>> another package, preserving the code in it's entirety. Yes, that's a
>> change for VMs that were [lazily] depending on language semantics to
>> protect those private package extensions, but that's life.
>>
>
> Yes, well the impression I was getting was that the discussion here
> has
> drifted away from the pros and cons of the Classpath VM interface, and
> towards ideas of creating your own, or reimplementing java.lang, or
> even
> forking Classpath.
Fair enough. But I'd really like to rope this back to the pros and
cons of the GNU Classpath VM interface.
>
>
>> Also, I don't know what the 1.4 and 1.5 Java API requirements on the
>> VM are, but given that GNU Classpath isn't there yet, isn't it even
>> plausible that may have something to add?
>>
>
> Yes, 1.5 *will* add new requirements to the VM interface. But the
> Classpath VM interface isn't some immutable static thing either.
> All I'm
> saying here is: how about crossing that bridge when you get there,
> instead of deciding out of hand that it isn't good enough?
Guess which version of J2SE we want to do...
geir
>
> /Sven
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] How much of java.* and friends does Harmony need to
write. Was: VM/Classlibrary interface
Posted by Sven de Marothy <sv...@physto.se>.
On Sun, 2005-06-05 at 06:21 -0300, Geir Magnusson Jr. wrote:
> That's not fair. I told you that *I* think that extending java.lang
> is a *bad idea*. You many not agree, but that's not the same is
> NIH. That doesn't mean that java.lang.VMObject can't be move to
> another package, preserving the code in it's entirety. Yes, that's a
> change for VMs that were [lazily] depending on language semantics to
> protect those private package extensions, but that's life.
Yes, well the impression I was getting was that the discussion here has
drifted away from the pros and cons of the Classpath VM interface, and
towards ideas of creating your own, or reimplementing java.lang, or even
forking Classpath.
> Also, I don't know what the 1.4 and 1.5 Java API requirements on the
> VM are, but given that GNU Classpath isn't there yet, isn't it even
> plausible that may have something to add?
Yes, 1.5 *will* add new requirements to the VM interface. But the
Classpath VM interface isn't some immutable static thing either. All I'm
saying here is: how about crossing that bridge when you get there,
instead of deciding out of hand that it isn't good enough?
/Sven
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 4, 2005, at 5:49 PM, Sven de Marothy wrote:
> On Sat, 2005-06-04 at 21:44 +0200, Santiago Gala wrote:
>
>
>>> So why create flexibility when there aren't
>>> options?
>>>
>>>
>>
>> to enable the development of other options?
>> without arriving to flexibility syndrome, good interfaces enable
>> competing implementations.
>>
>>
>
> If you're going to go off and write your own class library,
> implementing
> the VM-specific parts is the least of your problems.
>
>
>
>> Your question has exactly the same mindset that Sun people's
>> comments: "Java is free
>> enough, you have our implementation for free, why do you want another
>> one?" :-)
>>
>>
>
> No, it isn't the same mindset at all, because I can give you a
> specific
> list of grievances I have with the Sun license. But nobody here
> seems to
> be able to give list any specific problems with the GNU Classpath VM
> interface other than "It's not ours.".
>
That's not fair. I told you that *I* think that extending java.lang
is a *bad idea*. You many not agree, but that's not the same is
NIH. That doesn't mean that java.lang.VMObject can't be move to
another package, preserving the code in it's entirety. Yes, that's a
change for VMs that were [lazily] depending on language semantics to
protect those private package extensions, but that's life.
Also, I don't know what the 1.4 and 1.5 Java API requirements on the
VM are, but given that GNU Classpath isn't there yet, isn't it even
plausible that may have something to add?
geir
>
> /Sven
>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] How much of java.* and friends does Harmony need to
write. Was: VM/Classlibrary interface
Posted by Sven de Marothy <sv...@physto.se>.
On Sat, 2005-06-04 at 21:44 +0200, Santiago Gala wrote:
> > So why create flexibility when there aren't
> > options?
>
> to enable the development of other options?
> without arriving to flexibility syndrome, good interfaces enable
> competing implementations.
If you're going to go off and write your own class library, implementing
the VM-specific parts is the least of your problems.
> Your question has exactly the same mindset that Sun people's comments: "Java is free
> enough, you have our implementation for free, why do you want another
> one?" :-)
No, it isn't the same mindset at all, because I can give you a specific
list of grievances I have with the Sun license. But nobody here seems to
be able to give list any specific problems with the GNU Classpath VM
interface other than "It's not ours.".
/Sven
Re: [arch] How much of java.* and friends does Harmony need to
write. Was: VM/Classlibrary interface
Posted by Santiago Gala <sg...@apache.org>.
El sáb, 04-06-2005 a las 17:59 +0200, Sven de Marothy escribió:
(...)
> So why create flexibility when there aren't
> options?
to enable the development of other options?
without arriving to flexibility syndrome, good interfaces enable
competing implementations.
Your question has exactly the same mindset that Sun people's comments: "Java is free
enough, you have our implementation for free, why do you want another
one?" :-)
Regards
Santiago
--
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation
Re: [arch] How much of java.* and friends does Harmony need to
write. Was: VM/Classlibrary interface
Posted by Sven de Marothy <sv...@physto.se>.
On Sun, 2005-06-05 at 14:20 -0300, Geir Magnusson Jr. wrote:
> >
> > 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?
No, I can't speak for you. But it's been suggested on this list.
> 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.
Thanks for clarifying your position.
> 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...
Because I'm doubtful that we'll be able to produce a good specification
without anyone having done at least one implementation.
> But before we go leaping off to 1.6, how about 1.5?
And perhaps support 1.4 before that? I'd say wait until you get full 1.4
before worrying about 1.5.
> >> 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.
Ok. But then you won't be able to use Sun's class library. Which I
believed was the point here?
> 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?
I don't see any reason for wanting to prevent that. But I don't see why
you should go out of your way to enable it, if it means implementing
undocumented proprietary interfaces. And it does.
/Sven
Re: [arch] VM Interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 7, 2005, at 4:32 PM, Sven de Marothy wrote:
> On Tue, 2005-06-07 at 16:14 -0400, Geir Magnusson Jr. wrote:
>
>
>> Either one - if here, we can certainly suggest to classpath (and even
>> provide some code... I'm dying to contribute to something under the
>> GPL ;)
>>
>
> Geir,
> I know you were joking, but GNU Classpath isn't under the GPL.
> You know that. But there's been enough misconceptions about this on
> this
> list already. Let's not risk adding to them.
>
I meant GPL + Exception. And I wasn't joking. I think it would be
fun to contribute there. :)
geir
> GPL+exception != LGPL != GPL
>
> /Sven
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] VM Interface
Posted by Sven de Marothy <sv...@physto.se>.
On Tue, 2005-06-07 at 16:14 -0400, Geir Magnusson Jr. wrote:
> Either one - if here, we can certainly suggest to classpath (and even
> provide some code... I'm dying to contribute to something under the
> GPL ;)
Geir,
I know you were joking, but GNU Classpath isn't under the GPL.
You know that. But there's been enough misconceptions about this on this
list already. Let's not risk adding to them.
GPL+exception != LGPL != GPL
/Sven
Re: [arch] VM Interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 7, 2005, at 4:03 PM, 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.
>>>>>
>>>
>>> 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 :)
>>
>
> Learning from Sun et.al. and taking the best ideas is all good...
>
> My reaction was to the notion that a goal of Harmony should be to
> be API-compatible with Sun. Reading the first blurb quoted above,
> that seemed to be the suggestion (maybe I misread it). IMHO it's
> inappropriate to spend any (more) time worrying about API
> compatibility
> right now, when the possibility is so far off.
Agreed. API compatibility with Sun isn't a goal right now - but
having a VM/lib interface rich enough to support the semantics they
(and anyone else w/ a modern, complete implementation) need isn't
something we should ignore :)
>
> On the other hand, anyone who has any bright ideas for how the
> class/JVM
> API that Classpath has now might be improved please speak up
> (preferably
> on the Classpath mailing list, not this one?)
Either one - if here, we can certainly suggest to classpath (and even
provide some code... I'm dying to contribute to something under the
GPL ;)
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] VM Interface
Posted by Archie Cobbs <ar...@dellroad.org>.
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.
>>
>> 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 :)
Learning from Sun et.al. and taking the best ideas is all good...
My reaction was to the notion that a goal of Harmony should be to
be API-compatible with Sun. Reading the first blurb quoted above,
that seemed to be the suggestion (maybe I misread it). IMHO it's
inappropriate to spend any (more) time worrying about API compatibility
right now, when the possibility is so far off.
On the other hand, anyone who has any bright ideas for how the class/JVM
API that Classpath has now might be improved please speak up (preferably
on the Classpath mailing list, not this one?)
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [arch] VM Interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] VM Interface
Posted by Steve Blackburn <St...@anu.edu.au>.
Ahmed Saad wrote:
>Jikes RVM, Kaffe, SableVM, etc ----[implement Classpath-required
>classes]----> can use Classpath
>
>Harmony VM ----[implement Classpath-required classes]----> can use Classpath
>Harmony VM ----[implement Sun rt.jar-required classes(??)] ---> can
>use Sun rt.jar
>Harmony VM ----[implement X-required classes]----> can use X
>
>maybe Harmony would:
>1. determine which classes are required by each classlibrary
>implementation: GNU, Sun (is this legal), are there any others? btw,
>how will we know about Sun's? is src.zip enough ? (i doubt there are
>any published docs about this)
>2. work out a draft spec about what it takes for a common, well there
>was only GUN and Sun, classlibrary-VM interface based on what we found
>in Classpath and rt.jar
>2. implement adpaters for Classpath and rt.jar (what i mean is that
>Harmony spec will introduce a layer to abstract current
>classlibrary-vm interfaces)
>
>
This is exactly the approach we've tried to take with our VM-modularity
work, and that's what I was pointing to in my previous email. We've
pushed this n-m modularity issue fairly hard and we've nailed down the
specifics of just this sort of thing. I see it as a practical
solution. It need not have any performance hit, it provides a good
abstraction layer from both points of view. It has even allowed us to
effectively bridge C & Java implementations.
Forgive me if I'm missing something here, but it just requires that
people quit thinking in terms of simple APIs, which is where the problem
begins, and what seems to be the subtext of this entire protracted thread.
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200506.mbox/%3c42A4C1AD.5040902@anu.edu.au%3e
--Steve
Re: [arch] VM Interface
Posted by Ahmed Saad <my...@gmail.com>.
On 6/7/05, Archie Cobbs <ar...@dellroad.org> wrote:
> Geir Magnusson Jr. wrote:
[..]
> > 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.
>
> >> 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 :-)
[..]
>From what i understood from the GNU Classpath VM Integration Guide, a
classlibrary-VM interface is intended to provide implementation for
some basic classes that are needed by this particular classlibrary to
get the work done, correct me anybody, please? (are there any other
requirements for such interface beyond some hooks? (maybe true for Sun
rt.jar))
Jikes RVM, Kaffe, SableVM, etc ----[implement Classpath-required
classes]----> can use Classpath
Harmony VM ----[implement Classpath-required classes]----> can use Classpath
Harmony VM ----[implement Sun rt.jar-required classes(??)] ---> can
use Sun rt.jar
Harmony VM ----[implement X-required classes]----> can use X
maybe Harmony would:
1. determine which classes are required by each classlibrary
implementation: GNU, Sun (is this legal), are there any others? btw,
how will we know about Sun's? is src.zip enough ? (i doubt there are
any published docs about this)
2. work out a draft spec about what it takes for a common, well there
was only GUN and Sun, classlibrary-VM interface based on what we found
in Classpath and rt.jar
2. implement adpaters for Classpath and rt.jar (what i mean is that
Harmony spec will introduce a layer to abstract current
classlibrary-vm interfaces)
Apache can take this spec to the JCP and till it's approved the
adapaters will be enough (if sun changed the interface in the next
version we would work on a new adapeter. maybe there would be some
changes in the spec).
i haven't been down to a VM before but can such a thing be achived?
-ahmed
Re: [arch] VM Interface
Posted by Archie Cobbs <ar...@dellroad.org>.
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.
>> 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 :-)
>> 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.
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.
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?).
So in summary: I just don't get it.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [arch] VM Interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 6, 2005, at 9:11 AM, Archie Cobbs wrote:
> Peter Donald 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.
>
> 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.
>
> 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.
>
> 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? :)
geir
>
> -Archie
>
> ______________________________________________________________________
> ____
> Archie Cobbs * CTO, Awarix * http://
> www.awarix.com
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] VM Interface
Posted by Archie Cobbs <ar...@dellroad.org>.
Peter Donald 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?
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.
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.
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.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [arch] VM Interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 6, 2005, at 10:03 AM, Ahmed Saad wrote:
> On 6/6/05, Peter Donald <pe...@realityforge.org> wrote:
>
>> The reason being that their customers do not
>> want to be exposed to differences between rt.jar and GNU Classpath.
>>
>
> oh well aren't both implemented according to a well-designed exported
> API. So how there would be differences that would hurt the clients of
> this API (assuming that the GUN Classpath got completed and they are
> both might be retrofitted to be easily installed in this modular
> architecture even if they depend on some native libraries).
The differences come from implementation of that API. Conceivably :)
there are bugs in implementations of class libraries.
(Having one that we all share would be an excellent start to solving
that problem.)
geir
>
>
> regards,
> ahmed
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] VM Interface
Posted by Peter Donald <pe...@realityforge.org>.
Hi,
Ahmed Saad wrote:
>oh well aren't both implemented according to a well-designed exported
>API. So how there would be differences that would hurt the clients of
>this API (assuming that the GUN Classpath got completed and they are
>both might be retrofitted to be easily installed in this modular
>architecture even if they depend on some native libraries).
>
>
You are right but I am not sure the classlibrary has been specified well
enough for that
level of compatibility to occur. Even if it was specified well enough
every implementation
has bugs and sometimes application code ends up relying on these bugs or
working around
these bugs (with or without the developers awareness).
Consider something like xsl and its support in java. The specification
has always been
realtively complete but in many cases certain xsl sheets will only work
with one xsl processor
or may only work with acceptable performance in one xsl processor. The
classlibrary is even
more complex than this.
Cheers,
Peter Donald
Re: [arch] VM Interface
Posted by Ahmed Saad <my...@gmail.com>.
On 6/6/05, Peter Donald <pe...@realityforge.org> wrote:
> The reason being that their customers do not
> want to be exposed to differences between rt.jar and GNU Classpath.
oh well aren't both implemented according to a well-designed exported
API. So how there would be differences that would hurt the clients of
this API (assuming that the GUN Classpath got completed and they are
both might be retrofitted to be easily installed in this modular
architecture even if they depend on some native libraries).
regards,
ahmed
Re: [arch] VM Interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 5, 2005, at 10:06 PM, Craig Blake wrote:
> One potential use is for companies (and individuals) to work around
> particular performance limitations and bugs in the Sun VM while
> keeping the libraries they know inside and out. I imagine that
> could become common if Harmony ends up being as modular as we all
> hope.
>
> I am curious as to how much of the standard libraries would be
> rendered non-functional without the VM specific classes from Sun,
> however.
Agreed. But there is a reasonable argument to be made that it's in
Sun's interest too to see a common interface/bridge/foo between the
VM and class library, so lets not count them out of this. This is a
long project, and it's still early :)
geir
>
> Craig Blake
>
> On Jun 5, 2005, at 5:32 PM, Peter Donald wrote:
>
>
>> Hi,
>>
>> It seems like there is a little bit of heat being generated by
>> this topic due to confusion. While Geir has not actually stated
>> this anywhere I assume that the reason that he is advocating for a
>> VM interface that is independent of GNU Classpath is because he
>> has plans to interoperate with other class libraries.
>>
>> 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.
>>
>> Consider IBM - There are a few people here (both active and
>> lurkers) that are IBMers. They have publicly showed support for an
>> open source JVM on numerous occasions and I am sure they would
>> benefit considerably (as would Harmony) if this project was to get
>> to that stage. However I suspect that it is likely that they want
>> to stick with a derivative of Suns rt.jar for the moment. The
>> reason being that their customers do not want to be exposed to
>> differences between rt.jar and GNU Classpath. Given that IBM has
>> already re-written large chunks of the JVM I suspect that over
>> time they may move piecemeal to an OSS class library - at a pace
>> at which they can verify it matches Suns behaviour.
>>
>> Another possibility would be the people from Brazil who are
>> starting their own JVM and I would not be surprised if at some
>> point someone wants to reimplement the class library using with a
>> ASL/MIT or other license with fewer restrictions.
>>
>> I could be wrong but I guess the idea is to keep the options open
>> and encourage collaboration with both big buisness and other OSS
>> projects.
>>
>>
>> ---
>> Cheers,
>>
>> Peter Donald
>> *------------------------------------------------*
>> | You can't wake a person who is pretending |
>> | to be asleep. -Navajo Proverb. |
>> *------------------------------------------------*
>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] VM Interface
Posted by Craig Blake <cr...@mac.com>.
One potential use is for companies (and individuals) to work around
particular performance limitations and bugs in the Sun VM while
keeping the libraries they know inside and out. I imagine that could
become common if Harmony ends up being as modular as we all hope.
I am curious as to how much of the standard libraries would be
rendered non-functional without the VM specific classes from Sun,
however.
Craig Blake
On Jun 5, 2005, at 5:32 PM, Peter Donald wrote:
> Hi,
>
> It seems like there is a little bit of heat being generated by this
> topic due to confusion. While Geir has not actually stated this
> anywhere I assume that the reason that he is advocating for a VM
> interface that is independent of GNU Classpath is because he has
> plans to interoperate with other class libraries.
>
> 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.
>
> Consider IBM - There are a few people here (both active and
> lurkers) that are IBMers. They have publicly showed support for an
> open source JVM on numerous occasions and I am sure they would
> benefit considerably (as would Harmony) if this project was to get
> to that stage. However I suspect that it is likely that they want
> to stick with a derivative of Suns rt.jar for the moment. The
> reason being that their customers do not want to be exposed to
> differences between rt.jar and GNU Classpath. Given that IBM has
> already re-written large chunks of the JVM I suspect that over time
> they may move piecemeal to an OSS class library - at a pace at
> which they can verify it matches Suns behaviour.
>
> Another possibility would be the people from Brazil who are
> starting their own JVM and I would not be surprised if at some
> point someone wants to reimplement the class library using with a
> ASL/MIT or other license with fewer restrictions.
>
> I could be wrong but I guess the idea is to keep the options open
> and encourage collaboration with both big buisness and other OSS
> projects.
>
>
> ---
> Cheers,
>
> Peter Donald
> *------------------------------------------------*
> | You can't wake a person who is pretending |
> | to be asleep. -Navajo Proverb. |
> *------------------------------------------------*
>
>
Re: [arch] VM Interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 5, 2005, at 9:32 PM, Peter Donald wrote:
> Hi,
>
> It seems like there is a little bit of heat being generated by this
> topic due to confusion. While Geir has not actually stated this
> anywhere I assume that the reason that he is advocating for a VM
> interface that is independent of GNU Classpath is because he has
> plans to interoperate with other class libraries.
>
I thought that was a base assumption of the project - that a modular
architecture provides ways for different implementations to
interoperate.
Goal #2 from the proposal :
"2) create a community-developed modular runtime (VM and class library)
architecture to allow independent implementations to share runtime
components, and allow independent innovation in runtime components"
> 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.
Or write their own class libraries for whatever reason.
>
> Consider IBM - There are a few people here (both active and
> lurkers) that are IBMers.
I'm an IBM-er but can't and won't comment on IBMs position on this.
(I work in a completely different area of the company. It's a big
company...)
> They have publicly showed support for an open source JVM on
> numerous occasions and I am sure they would benefit considerably
> (as would Harmony) if this project was to get to that stage.
> However I suspect that it is likely that they want to stick with a
> derivative of Suns rt.jar for the moment. The reason being that
> their customers do not want to be exposed to differences between
> rt.jar and GNU Classpath. Given that IBM has already re-written
> large chunks of the JVM I suspect that over time they may move
> piecemeal to an OSS class library - at a pace at which they can
> verify it matches Suns behaviour.
>
> Another possibility would be the people from Brazil who are
> starting their own JVM and I would not be surprised if at some
> point someone wants to reimplement the class library using with a
> ASL/MIT or other license with fewer restrictions.
>
> I could be wrong but I guess the idea is to keep the options open
> and encourage collaboration with both big buisness and other OSS
> projects.
Yes - exactly.
geir
>
>
> ---
> Cheers,
>
> Peter Donald
> *------------------------------------------------*
> | You can't wake a person who is pretending |
> | to be asleep. -Navajo Proverb. |
> *------------------------------------------------*
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
[arch] VM Interface
Posted by Peter Donald <pe...@realityforge.org>.
Hi,
It seems like there is a little bit of heat being generated by this
topic due to confusion. While Geir has not actually stated this anywhere
I assume that the reason that he is advocating for a VM interface that
is independent of GNU Classpath is because he has plans to interoperate
with other class libraries.
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.
Consider IBM - There are a few people here (both active and lurkers)
that are IBMers. They have publicly showed support for an open source
JVM on numerous occasions and I am sure they would benefit considerably
(as would Harmony) if this project was to get to that stage. However I
suspect that it is likely that they want to stick with a derivative of
Suns rt.jar for the moment. The reason being that their customers do not
want to be exposed to differences between rt.jar and GNU Classpath.
Given that IBM has already re-written large chunks of the JVM I suspect
that over time they may move piecemeal to an OSS class library - at a
pace at which they can verify it matches Suns behaviour.
Another possibility would be the people from Brazil who are starting
their own JVM and I would not be surprised if at some point someone
wants to reimplement the class library using with a ASL/MIT or other
license with fewer restrictions.
I could be wrong but I guess the idea is to keep the options open and
encourage collaboration with both big buisness and other OSS projects.
---
Cheers,
Peter Donald
*------------------------------------------------*
| You can't wake a person who is pretending |
| to be asleep. -Navajo Proverb. |
*------------------------------------------------*
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Posted by Dalibor Topic <ro...@kaffe.org>.
On Sun, Jun 05, 2005 at 02:20:53PM -0300, Geir Magnusson Jr. wrote:
>
> 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")
Could you elaborate on those things? You sound as if there is some
option for downstream users on your mind, but you are not coming out
with it, and it is not very clear what it is from guessing what you
might be thinking of ;)
> >
> >
> >>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.
I beliee the confusion exists because someone else suggested reimplementing
all of java.lang with a rather odd justification, to be able to mix in
SCSLd code, that is not practicable nor legally possible to distribute ;)
Your argumentation jumped right into the middle of that and that may
have lead people to assume wrong things. Maybe you should simply start a
new thread, present a use case, show what breaks, and we can analyze it.
Hunting things down in this long htread seems to be very confusing for
everyone.
> >
> >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...
Given that no such options exist, it is not possible to make any
ammendments for them right now, right, as noone knws what ammendments
they would need? ;)
What are the options on your mind? Could you give us some nice scenarios, name some
names, to see what motivates the discussion and how we can fix the the
problems in the VM interface for those users and/or clear up any
misconceptions about it.
cheers,
dalbor topic
> >
> >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
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] How much of java.* and friends does Harmony need to
write. Was: VM/Classlibrary interface
Posted by Sven de Marothy <sv...@physto.se>.
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.
> 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.
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.
Reimplementing java.lang is more work.
> 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.
Maybe Java 1.6 will require VMs to be able to make breakfast; Should we
start designing a VM-toaster interface, just in case?
> > 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.
2) Because people who have Sun's class library already have Sun's VM.
What would they want with Harmony for?
3) Because I thought the main idea was a complete VM under the Apache
license. Not ASL+SCSL.
/Sven
Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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