> [Original Message]
> From: Sven de Marothy <[EMAIL PROTECTED]>
> To: <harmony-dev@incubator.apache.org>
> Cc: <[EMAIL PROTECTED]>
> Date: 6/3/05 11:07:06 AM
> Subject: Re: [arch] VM/Classlibrary interface
>
> Hello,
>
> >
> > > And you can circumvent the language protection (package private...)
> > > if you work hard enough too, I believe...
> > >
> > > Keeping out of "java.lang" seems wise if we can arrange it...
>
> > By writing _only_ java.lang and java.lang.*,
> > we can truly speak of a separate implementation.
> > Adding only _parts_ of libraries like GNU ClassPath
> > would mean that users would implement Harmony library
> > policies, not Sun's, FSF's, or anybody elses.
>
> Blatant Not-Invented-Hereism. This isn't about "Control over the
> implementation", this was about language protection features.
>
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. That includes the language
protection features like Geir's example of package private,
which are an interesting game of navigating class file
structures with reflection, etc. I've never tried that,
but Geir is right, I think it can be done if you try
hard enough.
> The FSF doesn't have any "library policy". What are you talking about?
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. If there are conflicts, then
reasonable discussion between the teams should be able
to solve them. For example, if a GNU Classpath method
depends on a specific feature of java.lang.System where
there is a conflict between the Harmony and GNU
implementation, good communication between the
library teams should be able to solve the matter easily
so both the Harmony JVM and JVM's that use GNU Classpath
as-is could use the resulting change, no matter
which side the change was ultimately on, perhaps
even it amounted to changes to both sides.
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! Just have
the Harmony class loader control the key packages
for JVM integrity and away you go. (Well, that may
be a bit much, but you get the idea.) ;-)
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.
>
> > By writing _only_ java.lang and java.lang.*,
> > we can truly speak of a separate implementation.
>
> Why do you need a seperate implementation?
The Harmony JVM implementation. Study out _any_ JVM
implementation and you will find that most crucial
classes in java.lang.* require native calls into the
JVM itself. Other packages doing native calls are
likely to call a shared object library .so/.dll for
such operations. But even if a JVM has its native
java.lang.* methods call a .so/.dll, those methods
are _intimately_ connected to the internal state of
the JVM.
This is the extent of what I mean. I don't want to
re-invent any wheels that don't need it.
Dan Lydick
