harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Hamid <ar...@cornell.edu>
Subject Re: [arch] How much of java.* and friends does Harmony need to write. Was: VM/Classlibrary interface
Date Fri, 03 Jun 2005 20:22:00 GMT
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.

[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.


Tom Tromey wrote:
>>>>>>"Dan" == Dan Lydick <dlydick@earthlink.net> 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

View raw message