Joel Spolsky podcast

Just listened to an interesting interview with Joel Spolsky of Joel on Software fame. He hires competent developers to work on some project. As the real needs of customers emerge, the project is adjusted or new projects are spawned. So his approach is to start with technology and "lead" customers, but then listen hard for their feedback and react accordingly. Very sensible.

AOP meets OSGi

The Aspects Equinox incubator project just announced its first release.

Now you can write AspectJ aspects, package them as OSGi bundles, and apply them to bundles which explicitly "opt in" to these aspects. The "co-opt" model is coming soon and will enable aspects to be applied to unmodified bundles (without them having to opt in).

JSR 277 draft spec.

JSR 277 has produced an Early Draft Review specification which I hope the Java community will review carefully. As a member of the Expert Group that produced the spec., I don't think it would be appropriate to express my opinion here, much as I would like to.

Spring-OSGi

The Spring-OSGi project is now public.

OSGi for the enterprise?

The OSGi Alliance recently held a workshop on applying OSGi to the enterprise. You might find it surprising that a technology initially created for small devices is starting to be used on large enterprise systems such as application servers.

But businesses need to keep their IT costs down, especially price/performance. Salaries for application developers, operations staff, etc. can be reduced by using languages such as Java and standardised middleware. But if that impacts performance, then price/performance suffers.

OSGi provides good support for Java modularity, versioning, and lifecycle management but is also efficient because of its roots in small devices. Modularity helps keep development and maintenance costs down; versioning and lifecycle management reduce operational costs.

So, apart from the coolness of OSGi technology, I would expect its price/performance to appeal to middleware vendors and their enterprise customers. I would also expect customers to see value in using OSGi directly, e.g. in conjunction with Spring.

JRE provisioning

Ethan Nicholas is experimenting with a browser edition of Java. I've also been thinking about JRE provisioning: installing the core of a Java runtime and having it download and install additional pieces as required.

To work well, this needs a modularised JRE - a JRE which has been broken into 'modules' with well-defined dependencies. This is happening in Apache Harmony¹ where modules are defined using OSGi metadata, as in this example of the NIO module:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Harmony NIO
Bundle-SymbolicName:org.apache.harmony.nio
Bundle-Version: 1.0.0
Bundle-ClassPath: .
Import-Package:java.io, java.lang, java.lang.ref, java.net,
java.nio.charset, java.security, java.util,…
Export-Package:java.nio, java.nio.channels,
java.nio.channels.spi, org.apache.harmony.nio

Then a provisioning mechanism is needed. In OSGi, dependencies are usually resolved statically. Before a module is executed, each of its static dependencies is resolved to some module which satisfies the dependency. For provisioning, dynamic dependencies are required and, fortunately, OSGi supports these. During class loading the relevant dynamic dependency, such as the need for a particular package, is resolved. This suits provisioning nicely: during class loading if the imported package is not installed, the corresponding module can be downloaded and installed and then the dependency can be resolved. Needs a bit of work, but not very much.

In addition to the basic mechanism, the Java standard may need tweaking to define what is supposed to happen when provisioning fails because of network errors.

Finally, for best results, the JRE modules would need carefully layering to ensure the necessary machinery, such as network access, is available before the first download is initiated and to avoid dragging in essentially unnecessary modules too early. This could take a lot of work since existing JREs aren't layered this way. However, it should be possible to demonstrate reasonable results without having to rework the JRE modules significantly.

It'll be interesting to see how Ethan gets on. Can he do without a proper module system or will he, for example, try to use the new Java module system, JSR 277, which is also planned for Java 7?

Footnotes:

1. For more detail, see this presentation, slide 23 and following.
   

Mind the gap

In software, things you haven't thought of cause the most trouble. 'Underlaps' are much worse than overlaps. "Mind the gap!" as they say on the London Underground.