JavaRoadmap
|
Size: 860
Comment:
|
Size: 2114
Comment: add gcj-4.2 / classpath issues
|
| Deletions are marked like this. | Additions are marked like this. |
| 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). | * 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). |
| Line 12: | Line 14: |
| Adding precompiled java packages (using gcj) makes applications run faster, although trades speed for space (memory and CD space). | * 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% ... |
| Line 22: | Line 25: |
| 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. |
|
| Line 30: | Line 41: |
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. |
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/java-roadmap
Created: Date(2006-05-16T18:16:34Z) by MatthewLange
Contributors:
Packages affected:
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.
JavaRoadmap (last edited 2008-08-06 16:35:43 by localhost)