JavaRoadmap

Differences between revisions 3 and 4
⇤ ← Revision 3 as of 2006-07-05 22:56:20 →
Size: 2114
Editor: dslb-088-073-100-163
Comment: add gcj-4.2 / classpath issues
← Revision 4 as of 2006-07-05 23:20:35 → ⇥
Size: 3004
Editor: 209
Comment: Prettify.
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Contributors''':
 * '''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; gcj offers the possibility to compile byte code to native code, which should be used for java components in main (covered in a separate spec :NativeJavaGcjPackages).
 * Updating to a newer classpath version is required for better java 1.4.2 compatibility and use of the gcjwebplugin.
 * 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 14: Line 21:
 * Make the Java components of OOo (the only java desktop application in main) faster.
 * Have a java plugin for browsers on all supported platforms (the non-free sun-java5 currently just supports i386). Although the functionality/compatibility might not be at 100% ...
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 19: Line 28:
== Scope ==

== Design ==		  * Anna, a powerpc user, expects Java-based games on the Web to work.
Line 24: Line 31:

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

 * Make the Java components of OOo (the only java desktop application in main) faster.
{{{ jbailey: How? }}}

 * Updating to a newer classpath/gcj version for better java 1.4.2 compatibility and use of the gcjwebplugin.

 * Package updated gcjwebplugin.
Line 29: Line 47:
 * Rebuild of packages using gcj-4.1 instead of gcj-4.1.  * Rebuild of packages using gcj-4.2 instead of gcj-4.1.
Line 33: Line 51:
=== Code ===

=== Data preservation and migration ===
Line 39: Line 53:
 * 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.

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).
  • Make the Java components of OOo (the only java desktop application in main) faster.

 jbailey: How? 

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