Hi Graeme, On Mon, 2005-11-07 at 17:03 -0500, Graeme Johnson wrote: > Split-class (ClassX & VMClassX) or customized-class solutions (Tim E's > Kernel classes) are different approaches to solving the same problem.
Not completely. I think they complement each other. The ClassX & VMClassX split describes at a high (java) level what the responsibilities of an runtime/execution-model are. Then the VMClasses are more like the customized-class solutions in case you have a traditional execution-model that is based on JNI/Posix like platforms. > Of the two approaches I believe that the customized-class solution > delivers simpler code and shorter call-paths as it avoids the need for > any runtime redirection. That can be an issue indeed. But by marking the VMClasses package private and final (or just have list in the jit/compiler) all calls to them should be able to be optimized away if needed. > In either case I think we want to determine how to build customized > versions of a reference implementation without resorting to cut'n'paste > duplication. IMO making the build process responsible for creating > customized versions of VM-dependent classes from a master version puts > the complexity in the right place (build-time vs runtime). Yes, that is mostly how it works with GNU Classpath based runtimes. At build time each runtime overrides/changes the few VMClasses for which it cannot use the vm/reference version. This seems to work nicely and makes it possible to share almost all of the glibj.zip classes as is. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/
signature.asc
Description: This is a digitally signed message part
