Hi! After a pause of more than one year, caused by some other higher-priority projects, I'm working again on the Jaos VM [0]. Since I left ETH, I can only work during my spare time on the project.
The Jaos VM is a JVM using GNU Classpath implemented on top of the Aos/Bluebottle kernel [1]. This kernel offers many useful features like garbage collected memory management, dynamic module loading, and object-oriented model. This makes the implementation of a JVM particularly attractive and simple. Jaos uses GNU Classpath out-of -the-box. Currently, it works with GNU Classpath release 0.5. No changes at all are required. Jaos has some charateristics which make it peculiar. First, the jitter generates code that follows the kernel conventions for data layout, thus the java modules are fully integrated in the system (interoperability with oberon requires no glue code). Second, the java reflection classes are implemented to work directly with the system's symbol tables (the same used by the oberon compiler) so that both compilers rely on the same metadata (this sounds .NETish, and in fact also is). Jaos is a jit-based JVM; the jitter is based on [3], which is an ideal compromise as it fastly generates good code for the i386 processors. The language used for the native methods and low-level implementation is Active Oberon, an extension of the Oberon language (an evolution of Modula-2 and Pascal). Thus, Jaos is only able to run code written either in Active Oberon or Java: third party code in C is excluded. This is no big problem (for the moment), as the core classes of classpath are quite complete; it may pose a problem with the java/awt package, because apparently most of the implementation are optimized (and thus in C). Another advantage of the kernel modularity and dynamic loading features is that it allows decide which modules are loaded. As an example, I can deploy only the Aos kernel, Jaos, and a stripped down version of classpath (and forget about Oberon itself) on a single bootable floppy disk. My plans for the future include supporting java/net, java/awt, simplify Jaos installation and handling, and fine-tuning the VM. I want to rely as much as possible on Java code, in particular for the graphical support (I'm thankful to Sascha Brawer, who is writing the font stuff in Java). As a JVM developer, I think it is important for Classpath to provide as much code as possible in Java itself: this provides a reference implementation, it is fully portable, and allows to quickly have a fully-featured running JVM; each JVM can then choose whether to rely on the default implementation or provide an own optimized one. I will shortly begin with the implementation of java/awt/* for Jaos, but I will try to work as much as possible with Java (ideal would be to have only one base class with graphical primitives like Graphics2D natively implemented, and the rest in Java). Obviously, I will contribute any Java code I need to add to classpath to make Jaos work. Jaos itself is also freely available. Thank you very much to the whole classpath developer team for the great work done! -Patrik Reali [0] Jaos: http://www.oberon.ethz.ch/jaos/ [1] Aos/Bluebottle: http://bluebottle.ethz.ch/ [2] Active Oberon: http://bluebottle.ethz.ch/languagereport/ [3] Cierniak et al.; Fast, Effective Code Generation in a Just-In-Time Java Compiler; PLDI-98 -------- Patrik Reali http://www.inf.ethz.ch/personal/reali http://www.oberon.ethz.ch/jaos _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath