Java 5 and OMII: SWOT Analysis

Strengths

• Java 5 is well established and is becoming the standard (if it has not already).
• Reduces bugs
• Cleaner and more robust code
• Significant performance improvements for both client and server side applications
• Generics - reduces class cast problems. [MJJ]
• Higher-level utilities for concurrency support. [MJJ]
• Memory management.
• Long term project - hence Taverna 2 will have to be based on Java 5
  • it will have to happen at some time, so why not now?
  • Is this a "Strength" - such a close inter-dependence could also be viewed as a "Weakness" or it could be both/neither. [MJJ]
• Happier Java programmers

Weaknesses

• Java5 bytecode is not backwardly compatible with the Java4 run-time. [JB]

Opportunities

• Third party libraries increasingly depend on Java 5
  • Sesame 2 (needed for scalable metadata store)
  • jMoby the BioMoby library for Taverna
• Better maintenance and compile time error checking
• Java 6 Beta already available (with important security features and enhancement) hence it should be time to move to Java 5
• Sysadmins embrace the Java 5 VM for the improvements on speed and maintainability
• Java 5 features may be of particular use to OMII products e.g. concurrency would be of much benefit to OGSA-DAI [MJJ].
• Use of Java 5 may be attractive to other projects who currently use it and may be considering using OMII products [MJJ].

Threats

• User requirements and demands [MJJ]:
  • Is there a demand for this move from our users?
  • Will projects who use OMII services or who want to use them accept a move to Java 5?
  • Are they in a position to make such a move?
  • Are any users tied to use only Java 4 [JB]?
  • Will using Java 5 prove a put-off for potential/current users (in the near future anyway)?
• Multi-platform requirements [MJJ]:
  • Some OMII products, e.g. OGSA-DAI, are required to be compatible with both OMII and Globus platforms.
  • If one provider moves to Java 5 and the other does not then there are two alternatives:
    • Products required to be compatible with both would be required to continue to use Java 4 features only until both platforms have moved to Java 5.
    • Products could use Java 5 features on the Java 5-compliant platform but would incur a split in their code base to a greater extent than at present with consequent increases in overheads in development, testing and releasing.
  • OMII and Globus should enter into discussion on this issue.

Miscellaneous

• OGSA-DAI perspective [MJJ]:
  • We're in favour of the move.
  • But OMII and Globus should synchronise their moves else we could not exploit Java 5 features.
  • Also any move must be user driven.
  • Advisable to test compilation under Java 5 and recommend Java 5 use at least 1-2 releases before making the actual switch to using Java 5-specific features.

• A perspective from Southampton OMII [DBC+JB]:
  • OMII distributions have supported and been tested against implementations of Java 5 since OMII 2.0.0 - OMII container and client libraries can be installed under the Java 5 run-time. If this is done we don't see an obvious reason why, e.g., Web applications compiled against Java 5 can't be deployed in the current OMII framework (but we haven't explicitly tested this).
  • Currently we compile the OMII infrastructure against Java 1.4. Preliminary investigations suggest there are no major difficulties in compiling against Java 5. But of course this would force users to install OMII against Java 5 runtime (whereas currently it is an option).
    • We guess this may be acceptable to most users, but it is a new restriction.
    • Note historically OMII has been quite prescriptive about Java versions, and probably many users are already accustomed to installing specific JDKs for OMII.
  • In the short term, however, given the assumptions under the first bullet above, we don't see an obvious technical reason for compiling this basic infrastructure against Java 5.