InfoQ Homepage JSR 277 Content on InfoQ
-
Requirements of a Standard Java Module System
Yesterday, Mark Reinhold posted the first public draft of the future of modularity in Java. As it is a draft, there are a handful of issues that still need to be agreed on - but it represents the consensus of what modularity in Java should look like. And with IBM being involved, there's more emphasis on interoperability with OSGi than there has been in the past.
-
Bundle.update: OSGi in Java EE, JSR 294 Marked Inactive
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.
-
Article: Java 7 Module System Concerns
In this article, Lukas Krecan, introduces the reader with some basic concepts of modularization, gives a roundup of some Java module systems and deals with how Project Jigsaw is connected to the upcoming Java 7.
-
Jigsaw - the death knell of JSR277?
Following up from an earlier post about modularising the JDK (which InfoQ covered earlier), Mark Reinhold posted the announcement of Project Jigsaw as part of the OpenJDK. Is this the death of JSR277?
-
JSR 277 Debate Renews Around Versioning
Debate has once again arisen in the community around JSR 277, which is a proposed dynamic module system for Java 7. The flashpoint of the debate this time around is the version numbering system that is planned for JSR 277 Java Modules (JAMs). InfoQ examined the discussions and arguments to understand more about the current state of JSR 277 and it's acceptance by the community.
-
Are JSR277 and OSGi coming together?
Last month we asked whether Sun were listening about OSGi; at JavaOne, it was clear that many others have. Not only are all of the main J2EE engines now OSGi-enabled, but Spring launched their OSGi-based Spring Source Application Platform. Fortunately, a number of positive changes have occurred behind the scenes with JSR277; read on for what's been happening.
-
Sun's Silence on JSR 277 Leaves Many Questions from OSGi Supporters and Few Answers
The expert group behind JSR 277 has been largely quiet despite questions from the community at large on its status and possible compatibility with OSGi. In recent weeks calls for information and criticism have become louder.
-
Spring Dynamic Modules for OSGi: simplified development of OSGi applications
The Spring Dynamic Modules for OSGi project, formerly known as Spring OSGi, released version 1.0 today. InfoQ spoke with SpringSource CTO Adrian Colyer and Spring Dynamic Modules project lead Costin Leau to learn more about this release and what it provides for the Spring community.
-
Debate: What role will the JCP play in Java's future?
Recently, Alex Blewitt described the Java Community Process (JCP) as dead, likening it to a headless chicken which "doesn't realise it yet and it's still running around, but it's already dead". This touched off a debate over the usefulness of the JCP and how much it will play a role in Java's future.
-
Java Modularity Proposal: iJAM
A new proposal, iJAM, has circulated on the JSR-294 and modules-dev mailing lists suggesting some changes to the logic supplied in the strawman proposal for JSR-294 'superpackages' and receiving some positive feedback.
-
Interview: Peter Kriens discusses OSGi
OSGi is a Java modular development specification. OSGi is used in a wide variety of applications, from mobile phones to enterprise servers and the Eclipse IDE. In this interview, Peter Kriens explains where OSGi came from, what sorts of applications it's useful for, integration with Spring, the JSR 277/294 debate, and the future of OSGi.
-
JSR 277 and JSR 291 Interoperability threatened by lack of a prototype
The latest salvo in the discussion of JSR 277, JSR 291, and OSGi appeared last week in the form of a post by Glyn Normington, spec lead for JSR 291 and Expert Group member for JSR 277. He is concerned that the Expert Group has not been presented with a strawman yet and that the Expert Group will end up merely rubber stamping the strawman rather than discussing it in detail and making changes.
-
OSGi and JSR 277 Debate Continues to Grow
The debate over JSR 277 (Java Module System) and OSGi (JSR 291) is picking up steam again, with the JSR 316 (Java EE 6) submission restarting the previous debate about the overlap between OSGi and JSR 277. InfoQ has collected and summarized several viewpoints and arguments around this debate.
-
OpenJDK Project Releases Java Module System (JSR 277) and Improved Modularity (JSR 294) EA Snapshot
The OpenJDK project has released early an access snapshot of the Java Module System (JSR 277) and Improved Modularity Support (JSR 294). JSR 277 addresses modularity from a deployment unit perspective. JSR 294 addresses modularity from a development perspective, introducing a new language construct, called superpackages, for information hiding.
-
Update on Java Modules
Glyn Normington has written an overview of Java modularity covering JSR 277, JSR 291 and JSR 294. He describes how each is different and adds value, and later responds to the question of why we need modularity support in the JVM, as opposed to custom classloaders (like OSGi).