Juke Box Hero, Got Stars In His Eyes

I learned Wednesday that I was named a JavaOne Rock Star for my Why OSGi? presentation with Peter Kriens at JavaOne 2011. Nice!

Bndtools at the OSGi Alliance

The OSGi Alliance has been using bnd for a long time in the OSGi build. bnd is used by the ant build to create the bundles and execute the compliance tests as part of our continuous builds. It is also installed in Eclipse as an IDE plugin to provide IDE support for compilation classpath and test execution by OSGi members working in the Expert Groups.

Recently Bndtools development has been underway to create a better integration of bnd with the Eclipse IDE for bundle development. Bndtools 1.0 was just released and is available for installation into the Eclipse IDE as a replacement for bnd's Eclipse IDE support.

Since the OSGi Alliance has long used bnd, we already had the bnd infrastructure in place for our build. All that we needed to do to start using Bndtools was to update each project's .project file (using the Add Bndtools Project Nature menu item). This simple change then enabled Bndtools to manage the project within the Eclipse IDE. The OSGi Alliance will continue to use bnd in the ant build, but for our Eclipse IDE use we have moved to Bndtools.

Thanks to Neil Bartlett, Peter Kriens and the other bnd and Bndtools contributors for their hard work in making bnd and Bndtools the premier tooling for OSGi development.

Java 8 and the 1990s

I attended the first Jigsaw session at JavaOne today where Mark Reinhold presented the latest on Jigsaw. After what appeared to be the end of the presentation, Mark continued on and began discussing why OSGi is wrong for using packages as the primary unit import and export between modules and why Jigsaw is right for requiring (aka. importing) modules (but apparently, and non-symmetrically, exporting packages and types). Mark made several strange arguments.

He found the idea of a resolver matching package importers up to package exports (essentially a broker pattern where the resolver acts as the broker) to be bad/complicated/etc. He prefers the developer to effectively be the "resolver" and declare the specific modules to be imported. This removes an important level of indirection between the thing being provided and the artifact providing it. This is like saying, "Don't use interfaces, use concrete implementation types," because we don't want to have to figure out how to map the use of the interface onto a concrete implementation type.

Mark also stated that requiring modules mapped well onto native package managers (e.g. rpm, apt) while importing package provided for no simple mapping. So therefore requiring modules is the way to go. It seems rather sad to me that the design of modules for Java 8 is being driven by the capabilities of native package managers designed in the 1990s for native code. Shouldn't the design of a module system for Java be driven by the capabilities and attributes of Java?

The Needs of the Many Outweigh the Needs of the Few

There is a discussion on the Aries dev mail list about a tool for checking semantic versioning. One of the issues misunderstood in the discussion is about the asymmetry in the treatment of versions for the roles of API consumer and API provider discussed in the whitepaper.

An API package p can contains several types. Some types must be implemented by the API provider and some are intended to be implemented by the API consumer. p.S may be a service provided by the API provider and used by the API consumer. p.L may be a listener implemented by the API consumer and user by the API provider. A syntactic analysis tool for versioning needs to understand the orientation of a type to decide whether a change to the type constitutes a major version change for the package or a minor version change.

The whitepaper does not discuss how the orientation of the type should be marked. It is beyond the scope of the whitepaper. OSGi now uses the @noimplement javadoc tag (from Eclipse) to indicate the type is not to be implemented by the API consumer (e.g. p.S). Types not marked @noimplement may be implemented by the API consumers (e.g. p.L). Adding a new method to p.S represents a minor version increment to package p as API consumers are not broken (while API providers are broken; but they have tighter version constraints, e.g. [1.0,1.1)). Adding a new method to p.L represents a major version increment to package p as API consumers are broken. Furthermore adding a new type to package p will not break API consumers. They are free to ignore it. But API providers must change to support the new type.

These are examples of the asymmetry between API providers and API consumers: an API provider must provide all of the API while an API consumer is free to use any subset of the API.

So in order for any syntactic analysis tool to properly work, the orientation of the types in the package must be properly marked so the tool can decide whether a change warrants incrementing the major or minor version. What is missing is an agreement on how to mark the types. I think this is something bnd and bndtools should provide. Perhaps a set of standard annotations.

For any API, we see there is an asymmetry in the relationships is has with API providers and API consumers. In general, there will (hopefully) be many more consumers than providers. So the semantic versioning scheme is oriented towards the many: the API consumers.

"... the needs of the many outweigh the needs of the few." - Spock.

PS. It has also been suggested that segregating consumer oriented types from provider oriented types by placing them in different packages is useful. But this does not remove the need for syntactic analysis tools to understand the orientation of each type (or each package) to provide proper advice about necessary versioning changes. And now you have 2 packages which each provider and consumer must import...

OSGi issue of Java Tech Journal

Java Tech Journal has just published an OSGi issue. It contains a number of great articles about OSGi including one I co-wrote with Peter Kriens on the new Core 4.3 spec. Check it out!

OSGi 4.3 Early Draft 3 now available

The latest draft spec from OSGi is now available for download. It contains the final RFCs for the changes to the Core 4.3 specifications. Also included are draft RFCs for some new specs for the next releases of the Compendium, Enterprise and Residential specifications.

Since this draft is just a draft, understand that things can change, even substantially, before the final specifications are completed.

The Pipes Are Calling

On the osgi-dev list, there was an interest raised into having a Planet OSGi feed aggregator like the Planet Eclipse and other similar planets.

So initially I looked into planet software I could run on the OSGi server. I found Planet 2.0 and Venus which is a fork or successor to Planet 2.0. Both of these are Python scripts which of course depend upon other python scripts. However I could get neither of them to work on the RHEL 4 based OSGi server. The runtests.py sanity test failed for each choice. The failures were different and are probably based upon the Python version on the RHEL 4 system and possibly some dependent python scripts I did not have installed. Given that RHN manages the OS including the Python version, I was not keen to attempt to update it to a later version of Python that I would have to manage myself. And so I gave up on the python scripts. I have the feeling that if these tools were written in Java (or some JVM based language) it would have been mush easier to get them to run on different machines since there is a uniform basic machine and libraries to depend upon.

In any case, I needed some other solution. Some more use of a popular search engine lead me to Yahoo Pipes. I was fairly easily able to create a "pipe" to collect a bunch of feeds, sort the feeds by publication date and generate a new feed of the aggregate! I had heard of Yahoo Pipes before but never played with them. They are pretty cool and it was quite easy to mash up a bunch of feeds into a new feed.

So checkout the new Planet OSGi feed served up by Yahoo Pipes.