Trying to map the current state of Java EE is not an easy task. It’s a bit like trying to map an entire continent: one that has been colonized for many years, has many well-established cities, is growing at a rapid pace and has an abundance of resources. Unfortunately, it is also a continent that still has many unexplored areas, shifting borders, changes in government and even a few places where wars have broken out.
Yet the developers and managers thinking about emigrating their companies to this vast continent still have to till the soil, plant crops, and hopefully harvest the results of their labors. They want guarantees that Java EE is not a swampland that may sink under their feet and, despite recent controversy and lawsuits, the current government (Oracle) isn’t going to abandon Java EE.
It’s safe to say, though, that Java EE is not swampland (although there are still some murky bits), and the government is not likely to pack up and leave anytime soon.
According to a recent statement by Oracle senior VP Steve Harris, “If Java is not successful, we will fail. We really want Java to be successful, so keeping Java open and having developers working in Java is really critical to our success.”
He also reemphasized that Oracle is all about profits. I read this as a good thing, particularly for Java EE developers. Java EE is where the money is.
Could this situation change? Of course. But even if Oracle did a complete about-face and abandoned Java, it likely would still survive in one form or another. There are simply too many people who know the language and the environment, and there are just too many good things about developing in Java. Add in the fact that there are so many people and companies involved with the advancement of Java, and it would be hard to imagine them simply throwing up their hands and moving to an alternative.
But that’s all speculation. What is the current state of Java EE?
Recent history
The most recent version of Java EE, version 6, was released in December 2009. It added quite a few new APIs and addressed a number of other issues.
Among the alphabet soup of new and updated APIs, Java EE 6 added Web Profile, Pluggability/extensibility, Dependency injection, Bean Validation 1.0, Managed Beans 1.0, DI 1.0, CDI 1.0, along with updates to EJB, JPA, Servlet, JSF, JAX-RS, Connectors, JAX-WS, JSR-109, JSP, EL, JSR-250, JASPIC, and JACC… whew!
According to Java EE platform lead, Roberto Chinnici, who spoke at the JavaOne 2010 conference: “We standardized dependency injection. In general, we made improvements to existing APIs and made them work together much better than before.”
He described it as a type-safe model of injection, not a string-based one. It is integrated with the Web-tier functionality and with JSF, JSP and EJB, is friendly to pre-Java EE 6 resources and services, and is deeply extensible.
Chinnici highlighted what he felt were some of the more noteworthy improvements in Java EE 6. Regarding the Java EE 6 Programming Model, he explained, “All the APIs in the model have a two-layer pattern with a declarative layer with annotations, which does most of the work, and a programmatic layer that offers more advanced functionality. Annotations are additive; developers can pile them on a class, and each one will specify a particular aspect and invoke some resources from the container, which trigger some behavior. But they will not clash. More services can be added with more annotations.
“This makes it possible to evolve code gradually and go from a plain Java class to an EJB to one with more services progressively without breaking any code or having to redo your application from scratch. It is a very smooth way to evolve your code as you need more services.”
One of the other key aspects of Java EE 6 is its extensibility. Said Chinnici: “We also defined some powerful extensibility APIs that will make it simpler to adopt third-party libraries and frameworks and integrate them into your applications without having to do manual configuration.”
This last aspect of Java EE 6 may be one of the most important. While Java has always been extensible to one degree or another, many companies are taking advantage of the new APIs. For example, JBoss has released JBoss AS 6, which is a profile-compliant version of Java EE (in other words, it has not obtained an official certification from Oracle yet). CloudBees is another third-party company to offer cloud-computing products such as DEV@cloud, which provides an integrated development infrastructure featuring continuous integration based on Jenkins (formerly Hudson), available as a software service; and RUN@cloud, which provides a platform service for enterprise Java applications.
And of course there is GlassFish Server, one of the first application servers to support Java EE 6. There are currently two versions of GlassFish: GlassFish Server Open Source Edition 3.1, and Oracle’s commercial offering. According to the GlassFish website, GlassFish offers “a modular, flexible runtime based on the OSGi standard, now with fully featured clustering with centralized administration of multiple clusters and high availability of stateful components. Developers also benefit from the simplified programming model and productivity improvements offered by Java EE 6.
“Because GlassFish Server 3.1 uses a microkernel architecture based on OSGi, developers can begin with the Java EE 6 Web Profile and use the Update Center to easily upgrade to the full Java EE 6 platform. GlassFish Server 3.1 also offers advanced features such as application versioning, application-scoped resources, and development tool support from NetBeans 7.0, Eclipse and other popular IDEs.”
The Oracle commercial version supports GlassFish Server distribution, includes the Open Source Edition and GlassFish Server Control, Active Cache for GlassFish, and native integration with Oracle Coherence Web. Key elements of the Oracle GlassFish Server include a modular architecture that minimizes overhead by only starting GlassFish Server modules that are required to service running applications. It supports application clusters for high availability and application scalability. It provides centralized administration, including provisioning of GlassFish Server to remote hosts.
The Active Redeploy feature enables rapid iterative development by maintaining session state across application redeploys. Oracle GlassFish also delivers certified interoperability with Oracle Fusion Middleware products, including Oracle Internet Directory, Oracle Virtual Directory, Oracle WebLogic Server and Oracle Access Manager.
Allaying some fears
Now while all these advances may wet the lips of some developers, there are many other out there who will shrug and say, “That’s all nice, but what does that have to do with me? Will I be left behind if I don’t try to adopt all these things?”
Short answer: no. One of the best things about developing in Java is that the platform has always striven to be invisible (or as invisible as possible). The underlying credo of Java has always been “write once, deploy anywhere,” and for the most part that remains true. Yes, some code may need to be tweaked if you transition from Java EE 5 to 6, but the developers I spoke to implied that it was a fairly trivial thing (programmers who have had different, real-world experiences, feel free to correct me if I’m wrong).
And perhaps the most important question developers might have is, “Will I have to give up my old tools as Java moves into the future?” Again, you shouldn’t have to. Because of the structure and implementation of any Java app, it doesn’t really matter what tools you use to develop your code. Once your app has been compiled into bytecode, it should be able to run on any JVM that can interpret the bytecode or JAR file that contains any special libraries required. Most of the popular Java developer tools out there such as Grails, Groovy, JRuby, Jython, Rhino and Scala should be able to do this for you almost seamlessly, and many tools remove most of the headaches you might face if you did it all by hand.
All this being said, there are still some areas where Java stumbles. One of the current items topping developer’s wish lists is lambdas (or closure), a feature that was added to C++ a few years ago. This may not be a big deal for many developers, but it’s not a trivial task. Mike McGarr, Java Center of Excellence lead and managing consultant at Excella Consulting, said, “I was amazed at how quickly the people at Microsoft implemented closure in C#.”
Other issues include addressing the distribution complexities, the size of the platform, phasing out orphaned APIs and, of course, performance.
Oracle is well aware of these issues and is working toward answers. As Harris pointed out, “The major themes of JDK 7 included support for multiple languages with InvokeDynamic, enhanced developer productivity through small changes in Project Coin, NIO.2 and file system APIs, and concurrent programming and the Fork/Join framework, which is driven as a community effort by Doug Lea.” He also remarked that the convergence of HotSpot and JRockit is leading to improvements in performance and serviceability in things like the G1 garbage collector.
Java SE 8 should cover longer-range projects such as modularity and closures. Harris added that with each Java SE release, there should be a Java EE release as well.
Finally, there all those clear skies hanging over Java—nary a cloud to be seen. Currently, Java EE 6 is designed and built to be deployed on a single, in-house server and does not directly support cloud computing. Support for cloud-based deployments isn’t scheduled until release 8, sometime in 2012 or later, and with all the cloud buzz these days one wonders if Java is missing the boat. It seems like everyone and their mother is touting cloud-based applications as the solution to all our problems (including tweaking our family pictures or watching movies on our laptops in airports).
Again Harris addressed this issue, stating, “It’s critically important that Java EE moves forward with issues associated with cloud computing as a platform. We are very committed to this.” A lot remains to be decided in this realm, and the JCP will be central to reaching an agreement (see the sidebar for more information). But, he insisted, “We should probably all agree that pushing the platform forward on the cloud-computing front is really important.”
Of course, that doesn’t mean you have to wait. As mentioned earlier, there are companies out there like CloudBees that offer cloud solutions today. CloudBees recently combined forces with Stax Networks to offer Java EE 6-compliant PaaS solutions such as DEV@cloud and RUN@cloud, which currently support Amazon EC2 (Elastic Compute Cloud)—please, no jokes about Amazon’s recent “break in the clouds.”
Sacha Labourey, CEO and founder of CloudBees, indicated that it is planning to expand its offering to support other cloud vendors. Based on its rapid integration of Stax technologies, it’s a pretty good bet it will be moving fairly quickly toward that goal. Today its products are free, but in the future there will be both free and commercial versions.
Labourey said that Java’s eventual support for cloud computing won’t be jump up and sting CloudBees. “While we are not on the JCP anymore, we obviously follow everything closely,” he said.
He was also very optimistic about the Java platform. He said that while there may be political confusion about Oracle’s proprietorship of Java, he believes Oracle will eventually learn to strike a balance between the open-source community’s desire to set Java free from any one company’s control and push the platform forward while still making a profit.
Excella’s McGarr is also very optimistic about Java. “It’s flexible, stable, you can deploy anywhere, it has an open JDK, and there are plenty of developers and a wealth of tools. It’s still the most versatile platform for next-generation enterprise development,” he said.
Inside the JCP
So how exactly does Java evolve? The answer is a bit complicated (and it’s changed over the years), but here’s the short version.
The JCP (Java Community Process) is comprised of companies and individuals interested in advances in the Java language and platform. Anyone can join the JCP. It’s free for individuals, US$2,000 per year for educational, governmental or non-profit organizations, and $5,000 per year for commercial entities.
Once you are a member, you can submit JSRs (Java specification requests). A JSR is a document submitted to the executive committee to propose the development of a new specification or significant revision to an existing specification. If approved, a group of experts is formed to develop a first draft of the specification that anyone can review. The expert group uses the public feedback to further revise the document and create the draft specification that will be used as the basis for the RI (reference implementation) and TCK (technology compatibility kit).
At this point, all the dark and scary licensing issues are worked out. Once these are completed, they are sent back to the executive committee for final approval. The completed specification, reference implementation and technology compatibility kit are then updated in response to ongoing requests for clarification, interpretation, enhancements and revisions. Once all that’s done, the JSR is pretty much ready for formal adoption.
One unique aspect of the process is that the expert group must submit a working implementation of the JSR and a working TCK before the change will be incorporated into future versions of Java or the platform. This may seem a bit wrong-way-round, but as Justin Kestelyn from the Oracle Technology Network said in a recent interview, “Proposals alone don’t mean much if you can’t show that your ideas can actually be implemented. I can submit a proposal for a time machine, but the implementation is going to be difficult.”
Now it may also seem like anyone who controls the executive committee controls Java, but the Java SE/EE executive committee has 13 members consisting of major stakeholders (such as Intel, Red Hat, SAP and, of course, Oracle). But it also includes individuals and even groups such as SouJava: Sociedade de Usuários da Tecnologia Java (a Brazilian-based Java development community), the Central Ohio Java Users Group and the London Java Community. Yes, there have been major shake-ups in the executive committee, some major disputes and even a few resignations, but the dust seems to be settling somewhat and a special election for the three open seats just wrapped up on May 9.
How much influence does Oracle have over the other executive committee members? Oracle’s Harris said, “[The JCP] has its flaws without a doubt, and there are lots of politics involved. But it is also without a doubt the best place for us all to sit at the table and argue over what we want to do with Java moving forward.”
Alex Handy contributed to this story.
