On Jun 6, 2005, at 10:01 AM, Aaron Hamid wrote:
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)?
Doesn't this imply that the GNU Classpath interface should add a
second API that *it* should comply with for symmetry? That way you
don't get dependencies on GNU Classpath internals?
geir
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
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
