Jeroen Frijters wrote:
You are correct, but why take the performance and complexity hit to
solve a non-existing problem?
The simpler solution is to just use class loaders as a modularization
mechanism. It is possible (since I have done it in my OSGi framework) to
create a class loader that handles libraries packaged as JAR files such
that some packages are externally visible and some are not. Thus, the VM
objects could be in another package and all have public access
modifiers, but they would only be accessible to classes inside the JAR
file, not outside of it.
Sure, it is not impossible to get access to the VM classes in this
approach, but none of the proposed solutions offer this guarantee either.
-> richard
Regards,
Jeroen
-----Original Message-----
From: Aaron Hamid [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 05, 2005 20:44
To: [email protected]
Subject: Re: [arch] How much of java.* and friends does
Harmony need to write. Was: VM/Classlibrary interface
I actually had not considered this issue which would seem to warrant
these classes living in the same package. But can not an equivalent
solution be constructed such that the implementations of these public
classes can hand the VM* classes references to internal
structures (and
vice versa) though well defined interfaces, instead of relying on
visibility modifiers to allow the VM* objects to access
private state of
java.lang classes, thereby allowing the VM* objects to live in a
separate package? Or am I misunderstanding your statement (or maybe
that is just too cumbersome)?
Aaron
Jeroen Frijters wrote:
You're missing the fact that moving these classes into
another packages
creates another problem that is much worse. Namely that you
often need
to access private state in the public classes, you can do
that by living
in the same package, that's why the VM* classes live in the
same package
as their public counterpart.
Regards,
Jeroen
