This part contains all release plans, the projects organization and the development process in general.
Draft 0.2 plan
The document lays out the feature set for the next major release of JNode designated release 0.2.
This plan is intended to guide the development towards our first major release. It is not a fixed plan that cannot be deviated from. Suggestions & remarks are always welcome and will be considered.
Release target
We want this release to be the first usable version of JNode where we can run real world Java programs on.
This means that we need a working filesystem, a stable virtual machine, a class library mostly compatible with JDK 1.1, a working TCP/IP implementation and way to install it on a PC. It is not expected to have a fully working GUI yet.
Additional features
To achieve the target outlined above, each team will have to add/complement a number of features. These features are listed below. The percentages specify finised work, so 100% means completed.
JNode-Core
- 100% - Dynamically (re)loadable plugins
- 10% - Plugin install, upgrade & uninstall framework
- 50% - Second level native code compiler target as good (native) code quality
- 100% - Security system
- 0% - Setup utility
- 80% - Implementation of java.lang package
- 80% - Implementation of java.math package
- 60% - Implementation of java.security package
- 90% - Implementation of java.util package
- 80% - Implementation of java.util.jar package
- 80% - Implementation of java.util.zip package
JNode-FS
- 80% - Virtual filesystem (in progress)
- 60% - Implementation of java.io package
- 90% - R/w ext2 implementation
- 20% - R/w fdisk services
- ? - Format services for ext2
- 95% - ATAPI driver
- 95% - CDROM (ISO9660) filesystem
JNode-GUI
- 0% - Textmode userinterface for use in installer
JNode-Net
- 25% - TCP/IP stack, client & server
- 75% - Implementation of java.net package
JNode-Shell
- 100% - Commands to modify the classpath
- 100% - Commands to run java code, both .class and .jar files from any location
Release milestones
Right now no date is set for this release. There will be intermediate releases reflecting the state of development on the 0.1.x series until the target is reached.
Looking towards the future; 0.3
The next major release after 0.2 should bring a graphical user interface, we should really consider using J2SDK 1.5 features like generic types and add numerous drivers for CDROMs, USB, Video cards.
Draft 0.3 plan
The document lays out the feature set for the next major release of JNode designated release 0.3.
This plan is intended to guide the development towards our second major release. It is not a fixed plan (as we have seen with the 0.2 release). Suggestions & remarks are always welcome and will be considered.
Release target
This release will improve the stability of the JNode operating system and enhance the usability.
Global enhancements
A major goal of this release is to reduce the memory footprint required by JNode. The VM will be enhanced to support this, and all parts of JNode will have to be more concerned about their memory usage.
JNode will become localizable and translations for some locales will be added.
Every new part of JNode will have to be localizable according to a set of rules that will be determined.
The one and only language for the source code of JNode is and will remain to be English.
The remainder of this page will describe the targets and enhancements of the various subprojects of JNode. The names between brackets in the enhancements sections are the names of the lead developer for that enhancement.
The enhancements are given a priority:
- Highest priority
- Second priority
- Lowest priority
Core: Virtual Machine & Operating system
The virtual machine will become more stable, reduce memory usage and will add support for Isolates (JSR 121). Furthermore it will enhance the J2SDK compatibility level.
The operating system will add support for power management and make enhancements for that in the driver framework.
An installer will be developed that is used to install JNode onto a PC system. This installer will put the essential structures/files on the harddisk of the PC.
A persistent storage mechanism for plugin preferences will be added.
Enhancements:
- Isolate support [ewout]
- Annotation support [ewout]
- Multi CPU support [ewout]
- Integrate MMTK garbage collector [ewout]
- Smart field alignment, to reduce the size of objects [ewout]
- Overall memory reduction [ewout]
- Power management support [ewout]
- API for halt, sleep & reboot of JNode [ewout]
- Installer [martin]
- Persistent storage for plugin preferences
- Access to detailed information about system information such as classes & their usage
- Fragmented plugin support [ewout]
Networking
The network layer will be enhanced to fully support wireless networks. Furthermore, the existing TCP/IP stack will be improved in terms of reliability, safety and speed.
Enhancements:
File system
The filesystem layer will become more stable and will be refactored to make use to the NIO classes.
Support will be added for a virtual filesystem that allows links between filesystems.
A new "system" filesystem will be added that gives access to a distributed filesystem that contains the JNode system information. This system information is about plugins, kernels & preferences.
Enhancements:
- Change file system api's to use ByteBuffers [fabien]
- Update java.io to latest classpath version based on NIO classes [fabien]
- System filesystem [ewout]
- USB storage driver [galatnm]
- Extend support for EXT2 to EXT3
- Add write & format support to NTFS
- Generic block cache for block devices [fabien]
GUI
The existing GUI will be improved in terms of stability, Java2D support and speed.
The video driver interface may be adjusted to make better use of hardware acceleration.
A user friendly desktop environment will be developed or integrated.
Enhancements:
- Enhance java2D support
- Improve use of hardware acceleration
- Improve font rendering
- Improve Swing awt peers [levente]
- User friendly desktop environment [levente]
Shell
The shell will be extended with a graphical console, in order to display not ASCII characters.
Enhancements:
- Graphical console
- Add Isolate command invoker
Developer support
We want to make life of the JNode developer much easier. This will mean adding good documentation and also provide ways to develop JNode in JNode.
Enhancements:
- VM support for debugging
- Implement JDWP debugging protocol [levente]
- Support for a java compiler in JNode [levente]
TODO list
The document states some of the TODOs with regard to future releases of JNode. There is no particular date when the targets should be finished, but it should give you some hints, what you could look at :
- XYZ Filesystem: There are many other filesystems that could be added to JNode. Or existing readonly filesystems could be extended for write support. A list of possibilities includes: NFS, Samba, ssh fs, ftp write support, ntfs write support, ...
- Partitiontool: We need harddisk partitioning support. That includes a commandline version like fdisk but could also be extended for a graphical version. The GUI version can be written using charva or swing or both
- Grubinstaller: Some code to be able to install grub to the harddisk. That means, install stage1 into MBR, stage1.5 as needed and for both files the hidden data structures have to be updated. A "highlevel editor" for the menu.lst file would be fine, too.
- HTMLDemo: Classpath contains a little "webbrowser", it would be nice as a showcase for JNode. It's contained in examples.zip, but it has to be extended, because at the moment it's only usable for testing classpaths HTML renderer
- Device Drivers: Device Drivers are a very important part of an operating system. If you have a peace of hardware that isn't included in JNode yet, and you have some hardware/lowlevel skills you're welcome to add support for it. This includes either adding support for a new hardware for an existing API (e.g. network cards, graphic cards, HIDs,...) but also adding hardware that was not present in JNode before (e.g. Framegrabber (bttv,..), CD Writer,...).
- SWTswing: Port of SWTswing to JNode. This is needed to be able to run eclipse inside JNode. BTW, if that works, porting eclipse is the next TODO on the list
- JSR80: Interfacing the current JNode usb api to the javax.usb api as descriped in JSR80 API Specification.
- JNodeTools: Implement a tool to create and edit the plugin descriptors. Either as a eclipse tool or standalone app (so it can be used in JNode too). See also here
- JNode Commands: We need to expand and improve the suite of JNode utility commands that can be run from the command line. Rather than reinventing the wheel, JNode commands should aim to be compatible with commands defined in the relevant POSIX specification; i.e. IEEE Std 1003.1, 2004 Edition
Student Projects
In order to imply students in JNode, I will expose here some projects.
Git repository
The gitorious project is located here : http://gitorious.org/jnode.
It's compound of:
- svn-mirror, which is a mirror of the subversion repository
- a set a clones of svn-mirror, one for each student project
Contact
If you are interested, you can contact me (Fabien DUMINY) :
Remarks
- Since it's a draft, that document may evolve
- In order to have some warranty of real work, I have contacted some schools to imply students in these tasks. These students will be served first and in the order of their arrival
Classical projects
Here is a list of classical projects.
Legend :
(A) : project assigned
Level :
(*) : easy
(**) : average
(***) : difficult
(****) : very hard
: unknow
Complete AMD 64 support
- Description : The 64bit port has some bugs but it's not exactly known where and how many. This task is especially difficult as the bugs have to be spotted first. Is this enough work for a student project ?
- Level : Timeconsuming (Depends on finding the bugs)
- Assigned to :
Complete multi CPU support
- Description: Multi-CPU support is broken. There are bugs in JNode's Apic implementation and the scheduler is suboptimal in regard to SMP. This project involves fixing the (L)Apic handling and if time permits replacing the scheduler with an SMP efficient one.
- Level : average/hard (many informations are needed to complete the task)
- Assigned to :
Complete the vesa driver
- Description : The current vesa driver need grub support to detect and set the video mode at boot time. The driver should be extended to become independant of grub (and be able to switch to any supported graphic mode).
- Level : hard (many informations are needed to complete the task)
- References : implements the vbe3 specifications and other references gathered on jnode site
- Assigned to :
Implement full ddx support without 2d and 3d
- Description : With ddx, which stands for full modesetting, you can detect the monitor, you can set any resolution, (sometimes you can rotate the screen) and you have multihead support. From the performance point of view, it will faster than a vesa driver but slower than a chipset specific driver
- Level : moderate/hard
- Assigned to :
Implement javax.comm API (A)
- Description : The javax.comm API allows to access serial and parallel ports in java. I have been told that the javax.comm package can't be used to avoid legal issues : the rxtx project has choosen the gnu.io package instead.
- References : specifications of the API, its javadoc
- Tips : use the RXTX library
- Level : easy
- Assigned to : Mihail Argranat (blog)
The git repository is located here
Implement new GC algorithms for better performances (A)
- Advice : contact Peter since he has ideas about the subject and could give good practices to avoid breaking jnode for such a task
- You should have read this and understood at least the Basic Algorithm. In the terms of that page, JNode's gc is a conservative, non-moving, non-generational, stop-the-world mark&sweep algorithm. Improvements can be many-fold, basicaly removing one of the "non"s Good information with much stuff about memory management and garbage collection can also be found on this site. You can find another explanation of the naive mark&sweep, with a graph on this site
- Level : This can be anything from easy to extremly hard. Depends on actual task.
- Assigned to : Loïc Rouchon, Benoit Sautel and Ismael Merzaq
The git repository is located here
Implement realtime specification for Java
- Description : It's also know as RTSJ and JSR-282
- Level : extremely hard
- Assigned to :
Implement virtio drivers for jnode (A) (*/**)
The git repository is located here
Implement write support for the iso 9660 file system
- Description : iso 9660 is a norm that defines how data are stored in compact discs (cdrom, dvdrom ...). For now, we have only a limited read support for cdroms.
- Level : Hard ?
- Assigned to :
Integrate JDistro
- Description : It would be great to have that advanced desktop in JNode. I am not sure if there is really a licensing issue or not (JDistro is GPL and JNode is LGPL)
- Level : Hard
- Assigned to :
Port jnode to another CPU
- Description : For now, we only support x86 CPUs but it would be great to have support for other CPUs. Examples : ARM (used in small devices like mobiles), PowerPC, ...
- Level : hard
- Assigned to :
Port jnode to grub 2
- Description : Currently, JNode uses the grub bootloader. Using grub 2 would allow to openup to more plateforms like, for example, non BIOS-based architectures (aka EFI ones).
- Level : average/hard (many informations are needed to complete the task)
- Assigned to :
Write a driver for a sound card
- Tips : implement a driver for intelhda since all sound chips nowadays comply with it.
- Level :
- Assigned to :
Write a driver for Serial ATA (sata)
- Reference : Wikipedia page about Serial ATA (sata)
- Tips : implement compliance with ahci.
- Level :
- Assigned to :
Write a file system checker (**/***)
- Description : Writing a file system checker would not only help ensure that a file system is clean at boot time (like linux distro are doing). It will also allow to help fixing bugs in the current implementations of the file systems. For each of these file systems, a checker could be a student project by itself : ext2, fat32, fat12/16, ntfs (I am not sure about that one since it's hard to get ntfs specifications). The first student to work on a file system checker will have to define an API because we don't have yet one.
- Level : Average (depends on the file system complexity)
- Assigned to :
write a virtual keyboard
- Description : look at that topic for more informations
- Tips : JDistro has virtual keyboard which should be made standalone for reuse in JNode but I am not sure if there is really a licensing issue or not (JDistro is GPL and JNode is LGPL) ...
- Level : easy
- Assigned to :
Write another desktop for JNode
- Description : To be specified with the student.
- Level :
- Assigned to :
Write SWT peers
- Description : SWT is the widget toolkit used by eclipse. It has a java API and rely on native peers for the actual display of widgets. To be able to use SWT, one should implement SWT peers for JNode.
- Level : average/hard
- Assigned to :
Generic projects
Here is a list of generic projects
Legend :
(A) : project assigned
Level :
(*) : easy
(**) : average
(***) : difficult
(****) : very hard
: unknow
Implement an API
- Description : which APIs ?
- Level :
- Assigned to :
Write a command
- Description : It could be a big command or a set of smaller commands. It should be Linux commands.
- Level :
- Assigned to :
Write a plugin for eclipse ?
- Description : for doing what ?
- Level :
- Assigned to :
Write drivers for old legacy devices
- Description : which devices ?
- Level :
- Assigned to :
Experimental projects
Here is a list of experimental projects
Legend :
(A) : project assigned
Level :
(*) : easy
(**) : average
(***) : difficult
(****) : very hard
: unknow
Study and experiment usage of gradle as a replacement of our build system
- Description : For now, we are using ant + a set of custom ant tasks. I think gradle, in addition to keep things from ant, maven and ivy, add interesting possibilities :
- groovy scripting ability : more flexibility than xml based build systems. For example, you can do something before and/or after a given (set of) task(s) : it could be used to transform ant's jar task into a jnode's plugin packager (a jnode plugin is a regular jar file which contain a plugin descriptor file)
- interaction with ivy : look at gradle's faq for ivy
- interaction with maven 2 : look at gradle for maven 2 users and gradle's faq for maven
- interaction with ant : look at gradle's faq for ant
- you can find main features here
- Level :
- Assigned to :
Study and experiment usage of OSGi to manage plugins
- Study and experiment usage of OSGi as a replacement of current jnode's specific plugin framework (inspired by eclipse's one)
- Advice : The developer will have to deal with with Classloaders. It sounds to be a very hard task; It might even happen that's not a suitable replacement for our current plugin framework;
Moreover, the incoming modules for openjdk7 (project jigsaw) might come in the way/interfere with osgi. So, in my opinion, it's an heavily experimental task !
- Tips : Look at one of these implementations of OSGi :
- Assigned to :