JavaRoadmap

Summary

Java provides an important platform for us for a number of reasons. It's a common teaching tool, used in schools. Much commercial and Free Software is written in it.

We will:

  • Improve the speed and correctness of our default Java implementation.
  • Update to the most recent versions of key infrastructure components, like ant and tomcat.
  • Offer a supported Java plugin for browsers on all supported platforms.

Rationale

Ubuntu has a commitment to Free Software. Because of this, we need to provide the strongest free implementation of Java that we can, and ensure that the packages in main work correctly with it.

Ubuntu also supports a number of different platforms. The Java VMs shipped in multiverse are not available on all the supported Ubuntu architectures.

Use cases

  • Willi, another end user, expects Java applets to work.
  • Adam, an administrator, wants to deploy an existing web application (likely J2EE) on a Ubuntu server.
  • Dave, a developer, expects to run current versions of Java, Eclipse, Tomcat, etc.
  • Cathie, a corporate user, wants to run company-internal Java desktop applications (that may require any existing JVM version).

  • Wanda, an end user, expects Java WebStart applications to deploy and run.

  • Klaus, a developer, expects a performance gain with gcj compilation, and can afford to perform the needed testing.
  • Anna, a powerpc user, expects Java-based games on the Web to work.

Implementation

  • Using gcj, compile to native code Java applications in main. (See https://launchpad.net/distros/ubuntu/+spec/native-java-gcj )

  • Synchronize major infrastructure packages from Debian Unstable (ant, tomcat5, and others).
  • Updating to a newer classpath/gcj version for better java 1.4.2 compatibility and use of the gcjwebplugin.
  • Package updated gcjwebplugin.

See agenda and discussion for uncertainties.

  • gcj-4.2 packaging: Mostly done as part of EdgyPlusOneToolchainRoadmap

  • gcj-4.2 testing: regular builds done in gcc-snapshot; should be done together with testing for EdgyPlusOneToolchainRoadmap.

  • Rebuild of packages using gcj-4.2 instead of gcj-4.1.
    • Either single applications
    • all packages.

Outstanding issues

  • gcjwebplugin is probably ready for promotion to main. Evaluate it for inclusion by default in -desktop. "The current version does not provide a security manager capable of handling Java applets. Applets have UNRESTRICTED access to your computer. This means they can do anything you can do, like deleting all your important data."

  • gij and other classpath-based implementations are still not 100% conformant to Java 1.4. Upstream work is continuing and every release improves the system.

BoF agenda and discussion

The update to a newer classpath and the implementation of the SecurityManager require an update to the not yet released gcj-4.2 version, so we should not rely on it for edgy(main). Three scenarios come to mind:

  • gcj-4.2 is not ready for edgy; the spec is obsolete for edgy.
  • gcj-4.2 is ready, but we decide not to move it main; we may want to use it for single applications (most likely gcjwebplugin).
  • gcj-4.2 is ready for main; we use an approach as done for dapper: decide even after the UVF if we can/want to use it for main.

CategorySpec

JavaRoadmap (last edited 2008-08-06 16:35:43 by localhost)