JavaRoadmap

Differences between revisions 1 and 6 (spanning 5 versions)
⇤ ← Revision 1 as of 2006-05-16 18:16:34 →
Size: 872
Editor: srv801
Comment:
← 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
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Contributors''': MatthewLange
 * '''Packages affected''': 		 * '''Contributors''': JeffBailey, MatthiasKlose
 * '''Packages affected''': gcj, java-based packages.
Line 9: Line 9:
The current java packages provide byte code, which is interptered on runtime. Updating to a newer classpath version is required for better java 1.4.2 compatibility. Sync major packes from unstable (ant, tomcat5).
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.
Line 12: Line 21:
Adding precompiled java packages (using gcj) makes applications run faster, although trades speed for space (memory and CD space).
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.
Line 16: Line 28:
== Scope ==

== Design ==		  * Anna, a powerpc user, expects Java-based games on the Web to work.
Line 22: Line 32:
=== Code ===  * Using gcj, compile to native code Java applications in main. (See https://launchpad.net/distros/ubuntu/+spec/native-java-gcj )
Line 24: Line 34:
=== Data preservation and migration ===  * 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.
Line 28: Line 50:
 * 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.
Line 30: Line 55:

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.

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.

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)