Skip to main content
Last updated July 12, 2016 19:43, by rjolly


This project stems from an effort to bring standard Java to off-the-shelf Android hardware. It was first implemented in a Pearl NB7 "Meteorit" netbook with Debian ARM + OpenJDK, where it ran directly in the X server. It can also run in a normal setup (Windows or Gnome) with a VirtualBox-like experience (the desktop can be put in fullscreen and back) except it is Java instead of some OS. Even when run on a standard host, it is meant to be as autonomous and self-sufficient as possible, as if the single, pure Java entry point to the underlying system. Think Android, with standard Java instead of Dalvik + Android API.

It comes with a Linux-like package management system, but based on Ivy, which brings the vast amount of Maven public repository software, and a powerful dependency management system. This is unlike Android, where each application has to provide all its needed items that are not part of the API.

Also unlike Android, in-place application development is made possible by providing a compiler which, together with dependency management, makes development of applications a similar experience to Unix, where required header and library packages are installed in the system prior to entering the build process. This puts the dependency management burden out of the build process (as all required libraries are already installed and in the classpath) thus simplifying it greatly : one basically just has to run javac and maybe jar and that is it.

Aside from applications, the goal was to create a system powerful enough to build itself, just like Linux is able to build itself. It was used for that purpose for the first time (and thus became self-aware) on Mon Jul 13 10:43:43 CEST 2015.

Not every Java application will run on Linoleum : they have to implement a specific interface, and to provide a Swing JInternalFrame that can be added to the JDesktopPane. This is a design choice, to avoid an emulation layer to adapt normal JFrameS to the JDesktopPane, which is difficult and maybe not even possible in the actual JDK. Also, nothing is done to avoid the infamous System.exit() which will be present in the average non specific application, and will kill the whole desktop on the first occasion. The consequence is that all applications need to be redeveloped from scratch. But I think that, due to the lack of a proper Java system until now, not a great deal of applications are suited anyway.

Unlike Unix and Android, the model of the Desktop is : one process, everything runs inside the same JVM. This is not unsafe, as Java is a safe, statically typed language. Again this is a design choice, as it demands much less resources from the underlying system, and allows a pure Java experience throughout the system (for instance : drag & drop, but this is just an example). One consequence is that the input/output/error streams are shared by all threads. Thus, the console acts as the de-facto syslog.

The desktop is meant as a graphical user interface, but nothing prevents it to run server software, like web or application servers, databases and so on. This would demand a JConsole or JVisualVM-like monitoring application to be ported to the system.

The Desktop comes together with the following bundled applications:

  • file manager
  • browser
  • mail
  • script shell
  • notepad
  • clock
  • image viewer
  • media player (requires Java Media Framework)
  • 3d model loader (requires Java 3D)
  • pdf viewer

The basic operation is that a file is opened through the file manager by the suited application, based on its extension. New applications can be installed through the package manager, which is operated from the (Rhino-based) script shell, with the install() command. See for instructions to run (and build) the software.


Linoleum running on a Pearl NB-7 "Meteorit" netbook



Please Confirm