Java: Difference between revisions

From OLPC
Jump to navigation Jump to search
(Major rewrite of the state of Java, including links to options for running Java, open bugs, etc.)
Line 5: Line 5:
Java is currently not shipped by default.
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:
Open source versions[http://www.jboss.org/feeds/post/java_is_finally_free_and_open] have only recently become usable[http://icedtea.classpath.org/wiki/FrequentlyAskedQuestions#Functionality_and_Testing]. While not shipped by default, people do install java. And governments may install it, along with other non-free software, in their versions of the distribution. It appears applets now work in the browser if java is installed.[http://dev.laptop.org/ticket/865]


* 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.)
In preparing java for wider use, two challenges might be getting something
appropriately sized for the olpc laptop (eg, efforts to make the jre less
bloated, or using something like JavaSE), and integrating with the
Gtk/C/Python infrastructure for collaboration, storage, etc.


* <tt>gcj</tt>, 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.
But the basic bottleneck, on this as in most things OLPC, is shortage
of people. The core team is focused on the core, and on each deadline.
The community fills in the many opportunties that leaves. And it doesn't look
like anyone is really pushing on Java yet.


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.
But sometimes work is happening without the wiki being updated.
So it might be worth writing the devel list, to create a less random guess at current state.


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.
Perhaps what will happen is someone with some applets or a java program
they care about will clean up the wiki instructions for installing java.
Some country will decide to ship java, and people will create content bundles
containing html and applets. Perhaps someone will ship a program compiled with gcj,
and the libraries included in their own ~20MB space budget. Someone will bang on
using jython for the sugar ui. And java will increasingly become an option.


== General Java Issues ==
⚫
== People and groups who have worked on integrating Java with the OLPC XO ==
⚫
* [http://confluence.concord.org/display/TMS/Java+on+the+OLPC 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.
⚫
* [http://weblogs.java.net/blog/cayhorstmann/archive/2007/12/the_olpc_and_ja.html 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.


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.
⚫
== JNLP Handler ==


* 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 <tt>libgcj.so</tt> 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. [http://confluence.concord.org/display/TMS/Shrinking+Java+Disk+Footprint] 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.
see [[JNLP Handler]]

* 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 <tt>Activity</tt> class or interface specification written in Java would vastly accelerate the creation and adoption of applications written in Java.

* Sugar seems to require setting low-level X window properties, which is of course not easily achieved in Java. See [[http://dev.laptop.org/ticket/5271 Ticket #5271]]. 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.

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

== 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 [[http://dev.laptop.org/ticket/8348 Ticket #8348]]. 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.

== gcj-specific issues ==

* The current <tt>gcj-devel</tt> 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 ==
== Installing OpenJDK Java ==
Line 47: Line 59:
sudo yum -y install java-1.6.0-openjdk-plugin
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.
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.

== Potentially-useful libraries ==
The [[http://java-gnome.sourceforge.net/ 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 ==
⚫
* [http://confluence.concord.org/display/TMS/Java+on+the+OLPC 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.
⚫
* [http://weblogs.java.net/blog/cayhorstmann/archive/2007/12/the_olpc_and_ja.html 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 ==
== Potentially interesting Java programs ==
Line 66: Line 91:
== Alternatives to Java on the laptop ==
== Alternatives to Java on the laptop ==


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


* http://swingweb.sourceforge.net/swingweb/
* http://swingweb.sourceforge.net/swingweb/

Revision as of 03:24, 8 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.
  • Sugar seems to require setting low-level X window properties, which is of course not easily achieved in Java. See [Ticket #5271]. 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.
  • 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.

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 [Ticket #8348]. 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.

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.

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.

Dynamic Scripting

Learn more about "Jython" to create dynamic scripting environments under Java.

See also

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