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.
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 platform.” He then offered the following solution as the way forward:
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.