Aaron Hamid <arh14 <at> cornell.edu> writes:
> As
> far as I can tell, there is no such standard interface. So the best we have
is to use the ad-hoc interface
> required by our most likely class library candidate (Classpath), and
simultaneously try to ignite
> interest in standardizing the aforementioned interface across ma
> ny VMs.
That's a rather weird thing to standardise, being the internals of a binding
between the library and the VM, and necessarily something that is in flux, as
VMs and class libraries change internally. And they do change quite a bit over
time ;)
> Obviously this is not going to gain us any leverage with existing
proprietary VM
> s unless they also retrofit their library - the only option in that case is
to excise everything but
> java.lang.* from our bundling of Classpath and try to glue on the remaining
portion of, say, Sun's
> library, or IBM's library; of course then those third party libraries must
not cheat and use some of their
> own unpublished VM-specific interfaces, which they already do.
Harmony is not a proprietary VM, so that's not really a problem for Harmony.
Retrofitting VMs away from different interfaces into GNU Classpath has been
done already in projects like JikesRVM, with very good results, and does not
seem to pose an unsurmountable challenge to VM developers in general.
> I would not base any policy on support for developers breaking language
rules. Yes you can "cheat" and use
> reflection to bypass visibility limitations (and I have even had to do this
on some occasions to hack
> around some things), but you leave compatibility and portability at the door
when you start doing such things.
+1.
cheers,
dalibor topic
