harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Lea ...@cs.oswego.edu>
Subject Harmonizing on modularity
Date Sun, 22 May 2005 15:04:07 GMT

No matter whether you think you are starting with a JVM written in
Java or a micro-kernel-ish one in C (which seem to be the leading
options), you will probably discover that you end up writing most of
it in Java.  For just about every major subsystem, you will find that
some of it has to be in Java anyway, and most of it turns out to be
better to write in Java.  Steve Blackburn mentioned some of the
technical issues with respect to GC. Similar ones arise with
concurrency support, reflection, IO, verification, code generation,
and so on, as has been discovered by people developing both
research and commercial JVMs.

One of the challenges here is that the Java programming language
curently does not make it possible to distinguish those classes
sitting in the JRE library (usually, the stuff in "rt.jar") that are
logically part of the JVM vs the normal APIs that normal Java
programmers are supposed to use. (Although most existing JVMs
dynamically enforce inaccessiblity of some APIs by exploiting rules
about bootclasspaths in some special cases, but this is not a general
solution.)

As one consequence, some people have been led to make all sorts of
now-well-known complaints about developers programming to the
platform-specific APIs of existing JVMs. This must be avoided in
Harmony.

Independently, there has been a lot of discussion lately of possible
language enhancements resulting in some kind of module support for
J2SE 7.0 (Yes, the one after Mustang) to provide a more general
solution to the need for semi-private interfaces among subsystem-level
components, as well as for similar issues that arise in layered
middleware, as well as higher-level escape-from-jar-hell issues.  Some
people would like to see a first class module system (see for example
MJ http://www.research.ibm.com/people/d/dgrove/papers/oopsla03.html,
as well as similar work at Utah http://www.cs.utah.edu/flux/) Some
people would like something more like a saner version of C++
"friends". I don't think that any of these have been subjected to
enough thought and empirical experience to make a decision about which
way to go.

So it seems to me that this would be a good opportunity to harmonize:
Help work on possible forms of language-based module support, work
within JCP and with other JVM providers to eventually propel this into
the standard, and help shape the basic structure of a second/third
generation JVM.

(Digression: The issues underlying all of this have long been a big
concern to me, but I spent a long time fruitlessly dealing with them
the wrong way. JVM providers don't want to standardize on the contents
of the APIs for intrinsics etc. But they should be pleased to
standardize on the way in which they are expressed.)


-Doug

Mime
View raw message