JavaRoadmap

Differences between revisions 6 and 7
⇤ ← Revision 6 as of 2006-07-05 23:44:54 →
Size: 2891
Editor: studiocity-motorola-bsr1-70-36-194-85
Comment: remove overalp with native-java-gcj
← Revision 7 as of 2006-07-06 00:00:07 → ⇥
Size: 3246
Editor: ip68-4-243-127
Comment: Adding end cases (real, but not necessarily helpful to gcj).
Deletions are marked like this. Additions are marked like this.
Line 29: Line 29:
 * 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.
 * Willi, another end user, expects Java applets to work.

Summary

Java provides an important platform for us for a number of reasons. It's a common teaching tool, used in schools. Much commerical 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

  • Anna, a powerpc user, expects Java-based games on the Web to work.
  • 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.

  • Willi, another end user, expects Java applets to work.

Implementation

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

  • Synchronise 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.
  • gij and other classpath-based implmentations 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 CategorySpec

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