Gah. :(
So if I am to understand this correctly: Classpath java.lang.* implementation does not rely on specifics of
any given VM* interface implementation, but said VM* interface implementations MAY rely on internals of
existing Classpath java.lang.* classes? (so there is a one-way dependency from the VM* implementation to
Classpath but not vice-versa, hence the "out of the box" claims?) And through deduction,
"standardizing" this VM* interface would also entail "standardizing" reverse access to
the class lib java.lang.* implementations (either through some informal agreement on package visibility
members *yuck*, or through a more sophisticated, but more cumbersome, API)?
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.
Sven de Marothy wrote:
On Mon, 2005-06-06 at 00:26 +0200, Santiago Gala wrote:
A few classes need to be modified:
You're a bit confused here. Of course the Classpath VM interface
requires the VM to provide certain classes. How else would it work?
That does not mean to say that classpath itself needs modification
