I'm sort of confused by this discussion also.
It seems to be about at what granularity we start introducing vm-specific interfaces/implementations. At some point
the class library has to interface with the VM. We can do that at a very high level of course, by simply subsuming the
entirety of java.lang.* and "avoid" this issue by simply making the java.lang package THE
"interface", but we certainly don't want to rewrite and be responsible for all that code if we can avoid it.
The only other alternative (at least that I have read) is some compromise whereby "core" classes rely on an
"even-more-core" VM-specific API that will necessarily be different for each VM. As far as I can tell, there
is no such standard interface. So the best we have is to use the ad-hoc interface required by our most likely class
library candidate (Classpath), and simultaneously try to ignite interest in standardizing the aforementioned interface
across many VMs. Obviously this is not going to gain us any leverage with existing proprietary VM
s unless they also retrofit their library - the only option in that case is to
excise everything but java.lang.* from our bundling of Classpath and try to
glue on the remaining portion of, say, Sun's library, or IBM's library; of
course then those third party libraries must not cheat and use some of their
own unpublished VM-specific interfaces, which they already do.
[vm]
[vm-interface]
[java.lang.* core (e.g. from Classpath)]
[rest of the class library (e.g rest of Classpath, or some third party library)]
I would not base any policy on support for developers breaking language rules. Yes you
can "cheat" and use reflection to bypass visibility limitations (and I have
even had to do this on some occasions to hack around some things), but you leave
compatibility and portability at the door when you start doing such things.
Aaron
Tom Tromey wrote:
"Dan" == Dan Lydick <[EMAIL PROTECTED]> writes:
Dan> That includes the language protection features like Geir's
Dan> example of package private, which are an interesting game of
Dan> navigating class file structures with reflection, etc. I've
Dan> never tried that, but Geir is right, I think it can be done if
Dan> you try hard enough.
There are two cases.
In the first case there is no security manager. All the code is
trusted. In this case, yes, using reflection you can work around
access protections. In practice I don't see how this matters, as the
code is already trusted... if it does something weird, well, so what?
It could also do weird things to your filesystem or anything else.
In the second case, when there is a security manager, then, no, you
cannot get around the access controls, even with reflection.
Dan> The underlying idea here is to make as few changes as possible to
Dan> as little of the java.*, especially java.lang.*, or other core
Dan> library packages in order to give the Harmony JVM runtime
Dan> environment the greatest flexibility for using libraries. Heck,
Dan> if it's done right, you might be able to use Sun's or IBM's
Dan> java.* library implementation!
I see where you're coming from, but I don't see how this furthers the
goal of Harmony, which as I understand it is to have a complete,
compatible, open J2SE implementation.
But then, I'm not really getting this part of the discussion. For
instance, why does Harmony need a VM layer different from the one
Classpath provides? I don't understand that.
Tom
