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
[EMAIL PROTECTED]
