Alex Blewitt, Kevin Seal and Alex Buckley discuss modularity in Java, answering questions from the audience: when is modularity needed, how to address modularity, what are the similarities and differences in modularity between Jigsaw and .NET, and what are the improvements in OSGi-based development?
Over the last few years, modularity for Java has been an active discussion topic. From the (now defunct) JSR 277 to the recognition of JSR 291 and the ongoing JSR 294, modularity is seen as a necessary step in Java's evolution. Even future JVM-based languages like Scala are considering modularity. So, what does modularity mean, and why should you care?
Since the last bundle.update, a number of interesting events have occurred in the OSGi and modular Java space. JSR 294 has been (automatically) marked as inactive, the Enterprise Expert Group has released draft 4, WebSphere will allow direct running of OSGi applications and upcoming OSGi conferences have early bird discounts and call for speakers finishing soon.
It's been a month since OSGi 4.2 was released. What's been happening in the OSGi space since then?
Over the past month there has been a lot of debate on the current state of the Java Modularity working group (JSR 294). Although the JSR tries to find common ground between different module systems (notably Sun's Project Jigsaw and OSGi), the current set of proposals are overly complex and introduce the world's first concept of a meta-module system. Can the Simple Module System save JSR294?
