Module System JSR should be based on OSGi concepts says OSGi Alliance
The fallout from the proposed Project Jigsaw deferral continues. After Mark Reinhold discounted OSGi, the OSGi Alliance have their say.
The main reason given for not adopting OSGi revolved around the
notion that whilst the rich dynamic component system would be ideal
for packaging, deployment and execution, Reinhold believes that it
is “not operative at compile time”. He went on further to say that
while it would have use for library and application modules, OSGi
would not be an option for modularising the platform.
Unsurprisingly, and perhaps understandably, the OSGi Alliance
offered a rebuttal to his claims today, and took the chance to
clarify their stance on the situation. OSGI President Richard
Nicolson offered background to the Alliance’s work in creating
their Java-based module system on the OSGi blog, before stating how
important it is for the Java development team to get it right:
Clearly, a modularized Java platform would complete this story:
reducing both bloat and memory footprint, improving startup times,
better accommodating embedded environments, and future-proofing
Java with removable components would be highly beneficial for Java
developers, architects and users.
Designing a module system takes time and experience and so the
OSGi Alliance supports Oracle’s consideration not to ship Java SE 8
with Jigsaw. Especially as an incomplete modularity design would
hurt the Java community. Yet, we should not delay the work on the
Java Module System JSR.
So, the OSGi Alliance seem in agreeance in deferring Jigsaw if
it was incomplete; a fairly democratic answer. But the most
intriguing part of the blogpost is their proposed solution – to
continue working towards a Java Module System as part of Java, as
outlined in JSR 337: Java SE 8 Release
Contents. This would obviously see OSGi providing the
forming the backbone for it. Nicolson affirmed this saying OSGi
should be “the cornerstone technology to modularise the Java
He then offered the following solution as the way
The Module System JSR should be based on OSGi concepts, and
enable similar maintenance, extensibility, and agility benefits for
the Java platform, creating a single, coherent modularization
approach from the Java platform up through the application.
OSGi was mooted seven years ago (yes, this is how long this
issue has been around) in the dormant JSR Java Module System
JSR 277, with many sticking up for the
module framework in the public ballot back in 2005. When you
consider that OSGi is still going strong today as currently the
only real module choice for Java, seven years on that assertion and
support seems well founded.
Finally Nicolson, in a call to arms to the Java community, asked
for the JCP, partners and developers to work alongside the OSGi
Alliance. It may seem like the only political move they can play,
but you start to wonder whether the OSGi’s solution is genuinely
the only option left on the table.
It’ll be interesting to see where Project Penrose, the experimental
Jigsaw/OSGi project, goes from here. The OSGi Alliance have put
their backing truly behind it, hoping to accelerate what has become
a laborious process, but it seems they’d rather go with their Plan
B of pushing for a JSR using OSGi standards
Are we now too far down the line in Java’s long lifespan to even
consider ripping up the floorboards just for the sake of
modularising the JDK? It’s taken years to get to this point, and
whilst getting it right is of paramount importance, will people
care when it arrives in JDK9?
Is it really worth the financial cost and man hours if it might be
delayed yet again? So many questions and not enough answers.
It’s a tricky one to call, Java undoubtedly needs a module system,
but perhaps not one so deeply entrenched and worth rebuilding from
the foundations. The OSGi make a very convincing case to reboot
efforts towards the Java Module System JSR as a solution, but will
that save Java in the long run? We’re not so sure.
It’s clear though that when the Expert Group make a judgement call
on Project Jigsaw, they’ll firstly defer to JDK 9 and secondly,
rule out the OSGi as an alternative. The wait will continue, but
it’s the next steps that remain crucial to Java’s ever continuing
quest for modularity.