Java: Difference between revisions

From OLPC
Jump to navigation Jump to search
m (make yum and X Window System links, use <trac> for tickets)
(Notes about GUI sizing and rotation.)
Line 27: Line 27:
* 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.
* 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.
* 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 <tt>java.awt.Toolkit.getScreenResolution()</tt> 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.
* 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.

Revision as of 00:32, 10 September 2008

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 (Java applets in the browser.)
  • 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.

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.
  • 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.

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. The first XO Linux distribution based on Fedora 9 will be 8.2.0. Current "Joyride" development builds leading up to the 8.2.0 release also are based on Fedora 9. Until 8.2.0 is released, in order to install openjdk, you must first obtain a developer key (Activation_and_Developer_Keys) and upgrade your XO to a Joyride or 8.2.0 release candidate (see Olpc-update).

To install OpenJDK (assuminng you are running an XO distribution based on Fedora 9 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/

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


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=162296"