JavaRoadmap

Revision 3 as of 2006-07-05 22:56:20

Clear message

Summary

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

Rationale

  • 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% ...

Use cases

Scope

Design

Implementation

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.1 instead of gcj-4.1.
    • Either single applications
    • all packages.

Code

Data preservation and migration

Outstanding issues

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