Java

From OLPC
Revision as of 05:32, 4 March 2009 by Fasten (talk | contribs) (Undo revision 197476 by Fasten (Talk))
Jump to navigation Jump to search

Overview

Java is currently not shipped by default.

The yum repository for developers, however, contains a couple of open-source options for executing and developing Java applications on the OLPC. These include:

  • OpenJDK, an open-source Java Virtual Machine that developers can use to execute Java programs on the OLPC. This includes plug-in support so Java applets in the browser work. Can only be installed on Sugar builds > 706 (see How to check the OS and firmware versions).
  • gcj, part of the Gnu Compiler Collection. gcj can compile Java source to either Java bytecode or executable code, including dynamically-linked executables (these require libgcj). gcj also contains its own Java interpreter, called gij. Programs compiled with gcj can link to code written in other languages compiled by gcc.

In developer versions of the operating system, developers can currently run programs written in Java, but not as full-blown Activities. The programs can create their own windows, and be switched to under Sugar's task manager. These environments are not complete, though. See below for general problems affecting Java on the laptop and specific issues with these environments.

Java developers are encouraged to update this page with issues, progress, and links to bug reports that hamper Java development on the OLPC. It is also recommended that developers work together to choose a preferred Java environment for the OLPC, so only a single set of runtime libraries need be distributed.

General Java Issues

The following issues affect the use of Java on the OLPC. These barriers need to be lowered to make Java an appropriate environment for the OLPC, and to make it easier for outside developers to port their Java applications to the OLPC.

  • Footprint. Later versions of Java have become quite large, both in terms of disk usage and of memory. OpenJDK 1.6.0.0 requires at least 75 MB of disk space. The libgcj.so file needed by gcj is at least 32 MB. It may be possible to strip out unused portions and improve compression in these environments, though, as some have attempted with earlier versions of Java. [1] It may also not be necessary to distribute the Java compiler and tools, although removing them may hamper the goal of allowing users to modify and recompile their code.
  • Activity code only exists in Python. Implementing an Activity properly in Java will possibly require a C interface to various services. Implementing these services in C would also greatly help the inclusion of a variety of programming languages, as most languages can link to C libraries. C libraries can be linked from Java using JNI (Java Native Interface) or through compiler-specific mechanisms, such as GCJ's abilities to link with native C code in several ways. TODO: Add links to various bugs.
  • As a corollary to the above, an Activity class or interface specification written in Java would vastly accelerate the creation and adoption of applications written in Java. An abstract class or interface would point out clearly to developers exactly which methods would need to be implemented, and might contain reasonable implementations of boilerplate code.
  • Sugar seems to require setting low-level X Window System properties, which is of course not easily achieved in Java. See <trac>5271</trac>. The requirement of setting low-level X window properties hampers activities from being written in a wide variety of high-level GUI toolkits.
  • GUI sizing issues. Fonts and controls are generally very small when running Java code. Perhaps a way can be found to set the default font sizes more reasonably so that Java applications do not require significant rewrites to set the fonts of every component. Luckily, a call to java.awt.Toolkit.getScreenResolution() properly returns 200, the resolution of the OLPC's display in dots per inch.
  • Screen rotation issues. Currently, hitting the screen rotate button on the OLPC does rotate the screen, but components are not repainted properly. It is unknown if any event is fired on screen rotation. Perhaps one of the methods on java.awt.ComponentListener is triggered (WindowListener doesn't seem to have appropriate events.)
  • Full-Screen assumption. The Sugar user interface expects that a window will be made full-screen. Java interfaces that are only designed to use the space that they need may look bad, and may require significant rewrites.
  • Missing fonts. The latest shipping configurations of the OLPC completely lack fonts with glyphs for many languages (e.g. there are no fonts with Chinese or Japanese characters) so these languages cannot be rendered in any application on the OLPC, including in the browser. This should probably be considered to be a bug in a supposedly-internationalized platform, and affects language learning.

OpenJDK-specific issues

  • Font problems. Currently, OpenJDK 1.6.0.0 only uses one ugly font due to misconfiguration of its font configuration files. See <trac>8348</trac>. Fonts for several other languages are also misconfigured, pointing to fonts that don't exist on the OLPC.
  • Menubars don't seem to work in AWT, although accelerator keys do. The Menubars are displayed, but don't respond to clicks.
  • The OpenJDK 1.6.0.0 file rt.jar is approximately 56 MB, and none of the files in it are compressed. This file contains almost all of the .class files for Java's API, which leads to its large size. However, a .jar file is just a zip file, and could be made smaller if the files were compressed and not just stored, perhaps at the expense of startup time (and memory usage) as files must be uncompressed first, then interpreted. Simply extracting and recompressing the contents of this file reduce its size to 27 MB. Timing tests for non-GUI Java programs that load a fair number of classes went from 9.0 seconds to 9.3 seconds when moving to a compressed rt.jar file, an acceptable slowdown for the space saved. However, programs that loaded the AWT GUI failed with a segmentation fault when using a compressed rt.jar file. This needs further investigation.

OpenJDK problems with Opera

  • OpenJDK 1.6.0.0 has problems running in Opera 9.52 on OS build 767. The JRE will run fullscreen after launching a page with Java content, then the Opera browser will come back into focus and then the Java applet doesn't run. Bringing up the frame will also show a stuck app that won't close (the JVM most probably).

gcj-specific issues

  • The current gcj-devel environment in yum contains many dependencies, and it's questionable if it works at all.
  • gcj's implementation of many Java libraries, including AWT and Swing, lags behind other JVMs, including OpenJDK.
  • Speed. Machine executables compiled with gcj are usually quicker to start than other JVMs, (due to optimizations having been done at compile time) but long-running programs tend to run about 6 times slower than OpenJDK, even compiled with optimization.
  • While many developers hope that they can create a minimally-sized, statically-linked executable using gcj, dependencies on unknown classes loaded dynamically at runtime usually makes this impossible, and doing so is deprecated by gcj developers. However, if several applications use gcj, having only one dynamically-linked libgcj.so file shared among the instances is greatly preferred.

Installing OpenJDK Java

The Restricted Formats page contains installation directions for the Sun Java distributions that are encumbered by non open source licenses.

OpenJDK is an effort by Sun Microsystems to release versions of Java which are and can be completely built using code under free and open source licenses. Working in conjunction with RedHat's IcedTea project, a fully open source bootstrap of Java 6.0 was first made available for Fedora 9. Release 8.2.0 is the first XO system software based on Fedora 9. If your XO is not running the latest release 8.2.0 also known as build 767 (here's how to check), then you should consider upgrading to it; the details are in the 8.2.0 release notes.

To install OpenJDK (assuming you are release 8.2.0 or later), open the Terminal activity and type: 

 sudo yum -y install java-1.6.0-openjdk

and press Enter to install Java without installing the browser plugin. To install the plugin as well, you may instead use: 

 sudo yum -y install java-1.6.0-openjdk-plugin

Note: The Java OpenJDK plugin is currently working in the "Web" browser activity in 8.2.0 and Joyride builds (as of 2008-08-27). It may not work with the Firefox2 or Firefox3 activities.

JVM-Based Languages

Java can be thought about as having three different parts:

  • Java the language
  • Java the API, that is, the classes and functions available in a standard Java distribution.
  • The Java Virtual Machine (JVM). This is an environment that executes Java bytecode to run programs.

Many languages besides Java can be compiled to Java bytecode and run inside a JVM. Adding a JVM to the OLPC would enable support of many of these different languages. For instance, Groovy, Jython, Frink, Rhino, Scala, JRuby, and many more. [2]

Potentially-useful libraries

The java-gnome libraries allows Java applications to use the GTK+ windowing toolkit, which is used by other parts of Sugar. This may allow applications to be written in Java, but retain much of the look-and-feel of other Sugar activities. The usually-needed TextView controls currently don't have Java bindings yet in the main releases, but an experimental branch is available with: 

 bzr clone bzr://research.operationaldynamics.com/bzr/java-gnome/hackers/andrew/textview/

The Eclipse SWT library allows Java applications to use native OS windowing toolkit. Already available in rpm as 'libswt'. Includes support for GTK as well as many other OSes. It is mature library available for about ten years and it is foundation of Eclipse IDE.

JNLP Handler

A JNLP handler is a program that handles .jnlp files, also known as Java Web Start files. This is a method for installing and automatically updating Java applications. When launching a JNLP file, the JNLP handler can query a server to see if the program has been changed, and automatically update it if so. See JNLP Handler

People and groups who have worked on integrating Java with the OLPC XO

  • Java on the OLPC, Concord Consortium has worked on getting Java Web Start to work on the OLPC to enable deployment of it's open source science and math software frameworks and activities on the OLPC.
  • The OLPC and Java, Cay Horstmann (the author of Core Java) has a blog entry about his efforts to get Java working on the OLPC he bought through the Give One Get One program.

Potentially interesting Java programs

  • PhET Interactive Simulations (University of Colorado)
  • Molecular Workbench, a GPL-licensed application for creating and sharing molecular, mechanical, and discrete-element simulations.
  • JBook, an open-source, full-screen EBook reader with a built-in list of Project Gutenberg etexts from which to choose.
  • JClic JClic is a set of cross-platform Java applications useful for creating and carrying out different types of educational activities like puzzles, associations, text exercises or crosswords.
  • MHP includes DVB-J, which could be used for interactive school TV channels.
  • Wikiversity courses are likely to require Java
  • GeoGebra is a free interactive geometry software for education in schools. Wikipedia lists alternatives.
  • Jmol, an open-source java applet (and application) for viewing 3D molecular structures. Children can, for example, explore the 3D structure and function of DNA as well as vitamins, drugs (such as anti-HIV drugs), or proteins (such as hemoglobin and its sickle disease variant common in Africa).
  • http://alice.org/ - Alice 3D Authoring system, from the Stage3 Research Group at Carnegie Mellon University. (judging from the hardware requirements that would probably be using the OLPC to the limits)
  • Powers of 10 (see: Powers of Ten (Wikipedia))
  • A quick search for open source mind / concept mapping software yields 3 possibilities: FreeMind, WoW (Web of web), and cmaptools, all of which are java-based.
  • ImageJ "a public domain, Java-based image processing program," Runs Everywhere, Open Source, User Community, Macros, Plugins ...
  • Mirai Math GNU Octave front-end. Allows to edit formulas and make calculations in native mathematical notation.

Alternatives to Java on the laptop

See "Thin client" for the implications of a server-based approach.

See also

Retrieved from "http://wiki.laptop.org/mediawiki/index.php?title=Java&oldid=197484"