The Janux Project

Michael Emmel

The janux project is and Open Source project focused on Java class library implementation.
It is closely tied to a sister SCSL project of the same name that will be available in the near future at blackdown. The goal of the Janux project is to port java to run directly on top of the Linux kernel.
In other words the only external interface is the Linux system calls. This means no dependencies on  libc pthreads etc.
Most of the Janux project is based on code from Cyrus Intersoft which had decided to open source there Java  implementation to support java on the desktop.

Request for desktop developers
First I'd like to ask anyone who has developed a java desktop interface to please contact me if your intrested in getting your
desktop running on top of Janux.  My email  is
Building Dynamic JNI
Currently the code is only avialable via CVS to get the source

Janux  is the start of the 1.4 port effort
cvs login
cvs -z3 co janux

Next type

Then runDemo

This will print out the results of various native calls.
The source is in demo/

At the end of the document a description of each package is provided  read the source Luke then
email  me with comment  or obseravations at the above email address

Speiros  Swing based desktop

More intresting to most people is the Speiros desktop this is a port of AWT on top of Swing  currently avialable for  jdk 1.3
Checking out Speiros
cvs -z3 co desktop

This is a complete java desktop implementation currently running directly on xlib.
The source for the core will be available from


Here's the  soon to be famous first screen shot : )
Speiros Desktop

Getting and build Dynamic JNI
Currently the code is only avialable via CVS to get the source

Janux  is the start of the 1.4 port effort  Dynamic JNI lays the foundation for that port.
After writng all the jni code for Speiros I decided there must be a better way.

cvs login
cvs -z3 co janux

Next type

Then runDemo

This will print out the results of various native calls.
The source is in demo/

At the end of the document a description of each package is provided  read the source Luke then
email  me with comment  or obseravations at the above email address


 I feel that java needs one "real" java OS platform with a viable user base. This platform will enhance to overall java market especially the desktop application market by providing a  strong java client operating system.
Provide a java operating system on the linux kernel which can run existing unix/X11 applications but also offers the Java api's as a first class system programing api with "peer" access to the linux kernel and graphics subsystem. Currently the JDK is presented and often implemented as one monolithic code base Janux is about defining internal apis for java implementors on the linux platform.


Develop "low" level class packages to support Java Class library implementations on Linux. A large part of this project consists of
defining  low level porting apis that provide a clean interface to the "pure" java class library implementations.  It is hoped that over time a set of api's can be developed that allow one to mix and match java package implementations from a number of vendors.
Thus  not only can Janux support multiple  AWT implementations for example but support AWT implementations from different vendors.
The J2EE platform is vibrant and widely excepted with a number of Open Source and commercial implementations available. It is hoped that the Janux project will encourage vendors to support the desktop with the same level of commitment.
Commercial vendors could for example provide accelerated and optimized implementations of the AWT for various platforms.
This is similar to the X11 implementations there is XFree86 but still a number of commercial X11 implementations are available.
But since the current J2SE editions are offered free of charge its not clear that there is a direct market for Java desktop implementations as there is for the Enterprise version. Successful commercial implementations will probably be tied to the bundling of a optimized version of  janux with custom hardware or some other indirect revenue model.



A implementation of AWT on top of the Swing API.
    The AWT packages are probably the most platform dependent part of  the Java system.  This tends to be the most problematic and
hardest  to implement part of the java class libraries.  If one can produce a viable implementation of AWT with minimal dependencies on
existing  platform ui's then your well on your way to a viable java operating system. The SwingAWT  accomplishes this goal by porting the AWT peer on top of a Swing application.  SwingAWT is currently implemented on a small number of XLib calls to provide basic graphics and windowing capabilities. It contains a java X11 WindowManager which allows X11 programs to run in the java desktop.  The low level porting layer and high level desktop interfaces are available on the Janux web site. The actual peer implementation is  available as a source code patch to the Sun VM  on the Blackdown web site.  The next implementation for  jdk1.4 will move the Java VM into the XFree86 windowing system allowing java full access to the graphics device and  allows java to become a first class API for the linux based operating systems.

Dynamic JNI

    Interfacing java with existing native code based has traditionally been done through the  JNI C binding interface. Dynamic JNI takes a different approach.  Dynamic JNI is based on the fact that most modern VM implementations contain a powerful runtime compiler. Currently this compiler is only used to convert java bytecode to native machine code for increased performance. I consider this something of a waste for such a powerful tool.  Dynamic JNI opens up the low level assembler of the jikes rvm and allows the native bindings to be generated at runtime. Also in Dynamic JNI a complete elf runtime loader is available allowing java to take control of the loading and interface between native code and java.   Dynamic JNI is the first part of a long term project to develop a rational boot sequence for the JavaVM.
I call it the CO-VM project. In the co-vm design a initial bootstrap VM is started which then loads co-vms based on the Jikes RVM these co vm can be written in java and fully implement the JVM.  This separation allows projects like Dynamic JNI that want greater control over the internals of the jvm to access the vm data structures as real java objects.  This separation greatly reduces the requirements on the initial boot VM. It does not need to be multi threaded nor have a GC or a verifier etc. This boot vm could be a version or RVM suns VM or one of the  numerous open source VM that are available.  The separation into bootstrap and runtime VM's is a win win situation, the co-vms can be written without having to handle startup issues and the bootstrap need not deal with having to instantly initialize a complex full desktop java environment.  Another effect is that research VM's written to run in the context of a Co-VM have complete access to a fully functional java implementation and can thus focus on modeling the research problem. This can be accomplished by delegation of various capabilities to another functional co-vm.

Janux/Speiros Desktop

The janux  VM implementation provides a single Frame  to access the screen. This frame is restricted to only allow lightweight components to be added.  The full swing api is available to the desktop programmer.  Above this most of the desktop are based on a optimized subclass of JDesktop.   Associated with the desktop are two XML based libraries and applications. All applications  are accessed via a RDF based catalogs.  These RDF catalogs are presented as popup menus a browser or links on a desktop.
When a desktop application is launched a ANT task is created and run. Thus the shell language for Janux is ant. In the case of java applications the ant task can either launch the application as a process in the current VM vastly improving overall startup and responsiveness or exec a new  standard vm which then runs as a regular X11 application.  In Janux some modifications have been made to the AWT and Swing to remove global locks for example the Awt Tree Lock and move them to a per application lock. This greatly increases the robustness of internal applications.  Since the internal launch feature is entirely optional  Janux only interacts with java applications as a X11  WindowManger providing no java apis for the application programmer.

JCK Compatibility

This work is not expected to directly provide any additional programming api for the application programmer.  It is focused on developing the equivalent of "system" apis for JVM implementors  and package developers.  Janux will provide some api's for "system" programmers since  janux takes control of the linux system from the traditional native desktop implementations there are some restrictions on what api are available for the desktop implementation since there is no underlying native desktop.  Currently this requires the desktop  implementors to restrict the desktop to a pure Swing application on top of a single root frame. AWT components must run in the context of a applications either in a separate vm or optionally as a janux application.  Its critical to understand that janux is about developing internal "system" apis for implementing the JVM and class libraries not providing additional general use application programming apis.
Description of Dynamic JNI package structure


This is the real core of the whole project currently it only contains the jikes assembler extracted from the jikes vm. see for more info.


Initial work on porting DirectFB to java for the 1.4 implementation of this is related to the parent project SwingAWT

Java "posix" project just and idea
Linux syscall interface and c calling thunks ( all java ). The Cool Hacks TM

Elf binary reader and runtime linker in java. A lot of work to get going.. Probably tons of uses but for this project its primarily to remove the native loader code dependencies in the jikes rvm and load the native code for the dynamic jni interface.

Hopefully a place for generic interface if we ever support multiple object formats

A hacked version of antlr allows real subclassing side project to migrate antlr to be a XML production system

Antlr parser for "native" languages. The goal is to translate c c++ etc. to a XML format then translate this to Java classes with all the native bindings set up. This will work with the Elf loader to ensure complete bindings on a per shared library basis. The idea here is to use all information available binaries headers source etc. to generate java classes that wrap the native code. I feel this can then be extended to translate the native code to java.

Initial antler parser for the c pre proccessor

./net/sourceforge/janux/parser/cfamily/c C to XML parse
r ./net/sourceforge/janux/parser/cfamily/c/cgram/
Original C grammar from the antlr web site
A classloader which r
eplaces a request for a class with a subclass I have some ideas for this

You are here : )

I use bcel internally to generate some classes part of a cool hack in system to hijack the jvm native method resolution process No plans to modify right now but since I hack everything I use I'm sure bcel won't be safe for ever.

original version antlr-2.7.1 A version of antlr with a small bugfix grep for MIKE
I plan to hack a bit on antler so this will diverge over time from the main antlr tree. see parser/antlr My main goal is to develop a parser generator which will allow you to create sax2 xml parsers which actually read non XML languages but present them as XML.

Description of Dynamic SwingAWT package structure



Java X86 emulator
Jikes rvm

A java os similar to janux

Java desktops which may be compatible with Janux

X11  Server in java

XLib in java

Links with no code

Java lobby discussion about Swing desktops most developers tend to think its not possible