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