eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The Java Platform, Enterprise Edition 6 specification is back, and with it will be a lot of flexibility for developers.
A Sun Microsystems-led group initially trotted out a Java EE 6 specification to the JCP (Java Community Process) in early April and then withdrew it 10 days later. That specification was known as Java Specification Request (JSR) 313.
The new Java EE 6 specification, which was released on July 3, is known as JSR 316.
JSR 316 is aimed at reaching a wider audience of developers.
Rod Johnson, CEO of Interface21 Ltd.—the maintainers of the Spring Framework, said, “I believe that this will be the most important revision of the platform since it was released nearly 10 years ago, and that it should be welcomed by users of the technology.”
Indeed, according to the specification, in the past eight years, the Java EE platform has grown and matured, and is now able to cover a wide range of enterprise and Web application development needs.
In addition, the Java EE platform has fostered a vibrant community and marketplace for additional technologies, frameworks and applications that work with the platform, the JSR 316 specification said. Some of these provide facilities that are missing from the platform. Others provide alternatives to platform facilities.
“A major theme for the Java EE 6 release is to embrace and support those technologies as part of the overall Java EE landscape, while also continuing to simplify the platform to better target a wider range of developers,” the specification said. “To that end we propose two goals for this release—extensibility and profiles.”
Rather than attempting to add the myriad technologies that Web and enterprise application developers might want to use, “we believe it is desirable to enable more of these technologies to cleanly layer on or plug in to Java EE application servers,” the JSR 316 specification said. By adding more extensibility points and more service provider interfaces, these other technologies can plug in to platform implementations cleanly and efficiently, and be just as easy to use for developers as the facilities that are built into the platform, the spec said.
Meanwhile, to address the issue of the increasing broadness of the Java EE platform, the backers of JSR 316 have introduced the concept of profiles.
“To refocus the Java EE platform on particular classes of developers and applications, we propose the introduction of Java EE platform profiles,” the JSR 316 specification said. These profiles will reference the Java EE platform, as defined by the JCP process and may include a subset of Java EE platform technologies, additional JCP technologies not part of the base Java EE platform, or both.
Interface21s Johnson said the “one-size-fits-all model is less and less appropriate.” He also noted that Java EE software vendors have had to “certify against a huge range of functionality that most of their customers will never use.”
Moreover, Johnson said he believes profiles are a good thing. No, in fact, he said theyre a great thing.
“At last, users will have the power to shop around for what they want, rather than what a specification committee thought they wanted, two years before the users start building the application,” Johnson said. “Its high time that a Soviet style command economy was replaced by some healthy competition.”
In addition, the JSR 316 expert group also will define the first version of a Java EE Web Profile—a subset of the Java EE platform targeted at Web application development. And the new specification also will include a pruning process for removing technologies from the platform that are no longer needed.
One thing the Java EE 6 specification does not include is the OSGi (Open Services Gateway Initiative). It simply says that work on modules is being considered in JSR 277 the Java Module System, which is targeted for Java Platform, Standard Edition 7 (Java SE 7). “We anticipate that Java EE 7 will build on that technology and thus we will defer specification of any potentially conflicting technology to a future release,” the JSR 316 specification said.
Peter Kriens, an OSGi evangelist and consultant at aQute, a software consultancy in Beaulieu, France, said: “I cannot think of one rational argument why JSR 316 would not choose OSGi today so we can get the advantage in Java EE 6. Can you?”
Kriens also responds to the issue of profiles.
“To address the problem that one size does not fit all, Sun proposes to create a few more sizes, called profiles,” Kriens said. “Surely that should fit all? Well, profiles have been tried in J2ME [Java 2 Micro Edition] and they failed in my opinion.”
In any event, its pretty apparent that Sun and the JCP passed on addressing the issue of OSGi in Java EE 6. Still, the specification is big a step in the right direction. Suns recognition that it can no longer dictate one way for everybody is all positive. And the flexibility granted by the profiles and extensibility changes is a definite plus.