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?

A possible path forward

• As we reconsider the shape of a deployed Eclipse and the provisioning story, we are looking at having a pool of plugins from which configurations are drawn.
• A configuration is just a list of bundles in the pool. This set of bundles forms a (hopefully) coherent set of function that is useful to users.
• Any number of configurations can be defined on one pool and a given configuration can be instantiated at any one time.
• The pool is logical. The bundles in the pool may not be physically contiguous. The pool may also be made up of data stores in different formats (e.g., one plugins directory, one Maven local repo, ...)
• Not everything in the pool or configuration need be formally and OSGi bundle, it just has to be able to be seen as an OSGi bundle. This could be analogous to the way we convert plugin.xmls to manifest.mfs transparently.
• The PDE state and associated target platform infrastructure would be updated to work on some API associated with pool and configuration management/interrogation.
• Target platforms are just another form of configuration. They can be managed by PDE or by a provisioning agent like any other configuration.
• The API for looking at the pool/configurations should be below JDT and PDE. This is a provisioning API.
• JDT can use this to discover interesting libraries to make available as classpath entries.
• The next step would be to give JDT a state and corresponding classpath container much like that of PDE and likely similar to what the Maven IDE plugin does today. At that point the state and container support from PDE is a candidate for merging into JDT.
• If we go this far then it has to be really easy to manage the target.