Modular Java

Recently there has been a renewed interest in Java modularity. There are several JSRs in the area and more telling, the update and interest in OSGi is surging. Java classpaths and JARs are hard to deliver and hard to manage.

Below are some rough points around Java modularity and what Eclipse midht do about it.

• OSGi presents a pretty reasonable module story for both static description of modules and dynamic deployment and execution of modules (aka bundles)
• Regular Java developers have a problem of getting an managing the JARs against which they are developing.
• Modelling JARs as modules and managing/delivering them as such would be useful to Java developers even if they could not run them as modules (e.g., if they are not running OSGi).
• JARs can, with limitations, be automatically converted into modules by inspecting their contained classes.
  • Example, Apache mangen could be used to discover the needed information.
  • This generated metadata is may not include all required packages and will lack version information but for development purposes will still be useful.
• Having converted permanently or transiently all JARs into modules, JDT can start to manage classpaths in terms of modules much as PDE does.
• PDE defines the notion of a "target platform". This is a set of modules against which workspace projects are built.
• Target platform modules are also candidates for use when launching and application.
• PDE gathers together the modules in the target and creates a "state" to model the dependency interactions.
• This state is used as the basis for the PDE classpath container which is then used to compute the compile time classpath for individual projects.
• Today, plain old Java programmers can successfully use plugin projects (and thus use the PDE target, state and classpath container) to develop their code without needed to eventually run on OSGi. This is an approach taken by some folks in the Apache Harmony project.
• This is not without issues
  • The classpath generated at launch time is a linearized version of all the entries in all the containers in the classpath. There may be duplication and ordering conflicts. Users need to be warned about that.
  • It is unclear what happens to the transitive dependencies. That is, A requires B and B requires C. A does not directly require C but C is indeed needed to run A (and B). So, assuming we launch some main() in A, does C get on the classpath in the launch configuration? If so, how and where?