Michael said:
It would be the best if Eclipse.org just moved up to tomcat5. The more debian's eclipse deviates from upsteam the more of a pain it is on both the debian maintainer and on upstream.The second option was done long ago, originally for Fedora.
Off topic but just to throw this out, this would seem to be the best (in terms of speed) theoretetical JVM:
This a a merged static and dynamic compilation system that gains speed in echange for a (slight?) increase in processor usage, resource usage, and diskspace usage.
A static compiler that can optionally embed code for profiling which can then be used for later static recompiling, which would re-optimize based on the code paths most used (think like what gcc can do with '-fprofile-arcs'). The static compiler would also optionally be able to embed enough information to allow the dynamic ahead-of-time compiler (no, that is not a typo, read on) to re-optimize. The resulting binaries would be linked to a dynamic compiler. The dynamic compiler would be able to JIT compile java code as is needed. The resulting native code would be cached, and stored to disk. While the program is idle the dynamic compier can perform ahead-of-time compilation of bytecode, as well as reoptimize the existing machine code it generated based on profiling information, as well as staticly compiled code that had the nessesary information embeded. (In the case of the native code geneated by JIT that information is can be gleamed from the original bytecode, which is not the case with staticly compiled code, so any needed information would need to be embeded.)
Obviously the dynamic compiler could also be used to run java code directly, and an interface for doing so should be provided.
(This mostly describes 'Excelsior JET', although I'm not sure that that system supports dynamic reoptimization of the executables generated by the static compiler.)