On Jun 3, 2005, at 4:34 PM, 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.
Why would I have to "get around" the access controls? I'm the VM. I
can do magic things, right? (I should be able to...)
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.
Yes. I could believe that there are alternative class library
implementations that a user might choose to use. With a clean,
standard interface, the user should be able to just plug-n-play
(modulo compatibility certification requirements) both the VM
implementation and the class library implemetation.
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.
I'm not sure we don't, other than the bit about extending java.lang,
which I just personally don't really like. I understand why it's
done - to just take advantage of the language protection features -
but I wonder if there are other ways that are equally as satisfactory
for the intended purpose.
geir
Tom
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
