Here is a plan for migrating ChoiceMaker from Java 1.4.2 to Java 1.7. Comments and feedback are welcome.
ChoiceMaker 2 requires Java 1.4.2 because ChoiceMaker 2 is built as an assembly of Eclipse 2 plugins and Eclipse 2 requires Java 1.4.2 for functionality that is critical to ChoiceMaker. For example, the Eclipse IDE and the ChoiceMaker compiler wonʼt run under Java 1.5 or later. (ChoiceMaker 2 also uses a custom, "single-jar" adaptation of the Eclipse-2 framework that allows Eclipse-2 plugins to run within J2EE containers. This single-jar trick won't work with Eclipse 3.)
ChoiceMaker 2 uses Eclipse 2 plugins mainly to look up implementations of various interfaces. A number of replacements would be viable: OSGi bundles, Eclipse 3 plugins, Spring modules, and Guice dependency injection. After researching these alternatives, OSGi bundles seem like the best place to start. OSGi stands for Open Services Gateway Initiative. It is a framework that has been under development by a broad consortium of vendors since 1999 and has recently achieved broad adoption as a packaging framework for Java modules:
(*) The Eclipse 3 plugin framework is based on OSGi bundles, and Eclipse desktop applications can use OSGi bundles nearly interchangeably with Eclipse 3 plugins.
(*) Most manufacturers of J2EE vendors have adopted OSGi bundles as building blocks for their application servers.
(*) Some stand-alone, OSGi-only application servers such as Spring DM and Eclipse Equinox have gained wide support within the Enterprise Java community.
(*) OSGi is being adopted by the research community, as a way of building collaborative, open-source tools.
By migrating from Eclipse 2 plugins to OSGi bundles as its component framework, ChoiceMaker software could be used to build Eclipse 3 and J2EE applications that would run under Java 1.7.
While OSGi is a good migration choice for ChoiceMaker, there are two risks that need to be mitigated. First, there is no standard for integrating J2EE and OSGi components. Even most J2EE vendors use OSGi bundles to build their application servers, there is significant variation in the degree to which these vendors expose OSGi functionality to client applications running within their servers. Some application servers,6 provide no way for client applications to use OSGi as an implementation strategy. Other application servers,7 allow limited OSGi integration. Finally, a third group of servers allow complete or nearly complete integration between J2EE and OSGi components within a client application. This last category includes Oracle Glassfish, Apache Geronimo, IBM Weblogic, and JOnaS.
A second risk is that it is not clear how to migrate the ChoiceMaker compiler to an OSGi framework. The ChoiceMaker compiler poses special challenges, because it generates Java source code that is then compiled to Java binaries. This code generation function doesn’t fit naturally into the OSGi paradigm. However, other projects have had to solve similar issues. There are at least two distinct approaches:
(*) The first approach, used by ANTLR and some other parser generators, is to generate Java source code outside of the OSGi server, at build time, and then to compile and package the Java code into OSGi bundles like any other Java source code.
(*) The second approach, used by the Equinox JSP compiler, is to wrap a code generator inside an OSGi bundle and run it inside the OSGi application server. The open-source Equinox JSP compiler uses the Jasper JSP compiler without alteration, and presumably this code could be used an example for creating an OSGi wrapper for the ChoiceMaker 2 compiler.
To address these two risks, it is proposed to do the migration from Eclipse 2 plugins to OSGi bundles in 5 iterative stages.
In the first stage, two core ChoiceMaker plugins would be migrated to OSGi bundles, and the bundles would be evaluated within an Eclipse 3 desktop application and a J2EE application server. This goal of this phase would be to validate that OSGi bundles can be used without modification in both an Eclipse desktop application and a J2EE server application, and to select the target J2EE servers for the remainder of the migration. This iteration is expected to take about a week of effort (over some longer period of calendar time).
The next iteration would be to migrate the ChoiceMaker compiler to the OSGi framework, either as an OSGi bundle (following Equinox JSP compiler example) or as tool that builds OSGi bundles (following the parser-generator model). This iteration is expected to take about a week of effort.
The third stage of the ChoiceMaker migration would be to migrate all other ChoiceMaker code from Eclipse 2 plugins to OSGi bundles. Once the first two phases are complete, this phase should be relatively straightforward and is expected to take about a week.
The fourth stage would be to assemble ChoiceMaker OSGi bundles into the CM Analyzer desktop application and the CM Server J2EE application. A Maven script will be created to automate each of these builds. This phase should take about a week.
The fifth and final stage of the ChoiceMaker migration would be to change ChoiceMaker code to eliminate 1.4.2 code styles that have been deprecated in Java 1.7. The main example of this kind of change is the replacement of untyped collections and iterators with typed collections and sets. Another example is the replacement of deprecated classes and methods, such as replacing certain uses of the java.util.Date class with the java.util.Calendar class. While these changes are not mandatory, they will eliminate many warning messages that a Java 1.7 compiler would normally generate. This will allow ChoiceMaker to build cleanly, which will make it easier to spot other, more significant warnings that a Java compiler might generate. This phase is expected to take a week.
(*) Port two existing ChoiceMaker plugins to OSGi bundles(50 hours)
(*) Select an approach for porting the ChoiceMaker compiler to OSGi and implement it(50 hours)
(*) Migrate remaining ChoiceMaker plugins to OSGi bundles(50 hours)
(*) Create CM Analyzer and CM Server from OSGi bundles(50 hours)
(*) Update ChoiceMaker code to Java 1.6 standards(50 hours)
Log in to post a comment.