Java 9, OSGi and the Future of Modularity

InfoQ today published the first part of a two part article written by Neil Bartlett from Paremus and Kai Hackbath from Bosch / ProSyst.


Its definitely worth a read. The article was written some time ago so is in advance of the latest delay to JPMS / Jigsaw (and consequently Java 9) that was proposed last week on the mail list and at JavaOne this week.  This is just the latest in a series of delays over many years and we suspect won’t be the last.

As a very quick synopsis the conclusions are: (more…)

Nimble OSGi

So I just sent a rather cryptic twitter message with the instructions:

posh -kc “repos -l springdm;add org.springframework.osgi.samples.simplewebapp@active”

I figure it’s probably worth a short note to explain what this is doing given the narrowband aspect of twitter communications.

This command is running an instance of the posh (sh)ell which ships with Nimble. There are two switch parameters parsed to the shell:

-c: Tells posh to execute the command passed in from the unix shell in the posh (sh)ell environment
-k: Tells posh to remain running after the command has completed and open a tty session for user input

Now we come to the actual commands:

repos -l springdm: tells posh to load the spring dm repository index into the nimble resolver

add org.springframework.osgi.samples.simplewebapp@active: tells nimble to resolve all dependencies for the spring simplewebapp from it’s configured repositories. (more…)

Is this an application which I see before me?

This post has been triggered by two interesting posts on the topic of what it is to be an application in an OSGi environment. This is something I felt I just had to get stuck in with as its exactly what we’ve been working on in the Newton project.

The way we’ve tackled this is very similar to the approach suggested by Mirko, except instead of using Spring-DM as the top level element in the model we’ve picked SCA.

SCA is a relatively new specification but it gives a vendor neutral way of describing the service dependencies and architecture of an application running in an enterprise environment.

The basic pattern is that a component which has a certain implementation (java, spring, bpel, c, etc) is able to publish a number of services (over a range of protocols – in-memory, RMI, WS, JMS, etc) and consume services from other components via references. The combined unit which is the component, it’s services and it’s references are then packaged in an entity called a composite. (more…)

A New Hope

A long time ago in a galaxy far far away…

A group of rebels formed the OSGi Alliance, an alliance against the empire (or at least monolithic code empires). The alliance was created to champion an ideal (in CS terms a specification) which described a standardised way for modules of Java code in a single virtual machine to interoperate without requiring the JVM to be restarted.

The specification was simple to understand and many were drawn to it due to the elegance of its implementation. In time many who chose this new life found that despite the simplicity of the specification championed by the JEDi alliance they could nevertheless wield wondrous powers not seen before in the Java world. (more…)

To Be(*) Or Not To Be(*) That Is The Question

(*) Included in an API bundle.

There’s been a lively debate on the OSGi mailing list over the past couple of weeks surrounding the issue of whether an API should be packaged with it’s implementation in one bundle or whether it should be split up into two bundles (one for API and one for implementation).

I think it’s fair to say there are a range of opinions on the subject. What is clear however is that there is no one size fits all answer to this question. As a developer or architect you need to consider the use case your API and implementation are going to be put to in order to make the “correct” decision.

The fundamental issue (more…)