Jeroen I think there are at least two perceived problems being voiced:
* aversion to the idea of "polluting" a standard library distribution (e.g.
Classpath) with VM-specific interface implementations. Although there have been
assurances that such work is trivial and the interface is always-changing, it makes it
harder to decouple the VM from the class library (although another opinion is that this
is not a goal of Harmony anyway). The fact that all (?) VMs using the Classpath
library must make modifications to Classpath itself is an indication that perhaps
standardization on interfaces (not implementations of course) would be beneficial.
* uncomfortableness with relying on language visibility modifiers alone to
prevent user code access to these internal APIs (this I am personally not that
concerned about)
Not to be pedantic - but for purposes of clarification can we quantify the "performance and
complexity hit" for using well-defined interfaces as opposed to carnal knowledge between the
class library and VM interface implementations? From what I have understood, for example, of the
JikesRVM, these sorts of things are candidates for some heavy optimizations - especially given that
these interfaces should not be used by user code at all, and should probably not be
reloaded/unloaded/subject to traditional class loading issues (perhaps use some modularization,
annotation, or magic keyword syntax that allows aggressive optimization of otherwise
"public" interfaces?).
Aaron
Jeroen Frijters wrote:
You are correct, but why take the performance and complexity hit to
solve a non-existing problem?
Regards,
Jeroen
-----Original Message-----
From: Aaron Hamid [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 05, 2005 20:44
To: harmony-dev@incubator.apache.org
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
