This article is sponsored by the Java Community Process.

A Conversation with Bill Shannon and Roberto Chinnici

---

Frank Sommers: The JSR for Java EE 6, JSR 316, was submitted to the JCP in July. What are the main themes for EE 6?

Bill Shannon: We've been doing Java EE for quite a while now, and the EE community has become a vibrant place, with lots of things going on. There are now alternatives being created to various facilities in the EE platform, and lots of pseudo-competitors emerged.

We are looking at all the great stuff going on in and around Java EE, and have really been inspired by that. For EE 6, we are trying to find a way to manage those things, and embrace this very rich world of Java EE in a manner that makes sense for developers. That desire is among the main drivers for the direction we're going with Java EE 6.

One of the main themes for EE 6 centers around extensibility. Already, it is clearly possible to build a lot of facilities on top of Java EE, but we think there is a lot more we can do in that area to make it easier for people to build technologies that work well with Java EE, that integrate more easily with EE, and that make it easier to develop applications that use some other technologies that aren't part of the platform, but work well with the platform.

So we're going to focus a bit on extensibility in Java EE 6, have more pluggability points, and make it easier to compose applications out of many of the different technologies that are available in the enterprise Java world and beyond.

Another thing that we're going to focus on is the introduction of profiles to the EE platform. The JCP defines a very specific notion of profiles, and we're going to take advantage of that notion here.

Java EE continued to grow over the years and mature, but it's also gotten bigger. There are a lot more facilities than there were when we started, and we're finding that some developers who might be interested in Java EE are intimidated by the amount of stuff that's there.

To attract more of those developers, and to make it clear that they can actually use EE for simpler things, too, we are considering introducing a new profile, the Web Profile, focused at Web application developers.

The Web Profile would effectively be a subset of Java EE, providing just the important capabilities that Web application developers need. You're clearly not going to write all of your complete, high-end enterprise applications using a Web profile product, but there's a wide variety of simple applications that you could write with this profile. Combining that with the extensibility support, it would provide a very good base for building on and adding additional Web frameworks and capabilities that you might need.

We are also going to define additional profiles of different sorts in the future. What those might be, we haven't gotten that far yet. We think there are other opportunities to define profiles to attack particular markets or application development needs, and we'll be looking at that, after EE 6.

The third major focus in EE 6 is something we call pruning. As I said, the platform has grown over the years, and part of that growth has been the accumulation of technologies that are not quite as important or interesting now as they were at the time we added them. Some of them were replaced by newer technologies that we think are a better match for what developers need these days.

In pruning out the parts of Java EE that are not as widely used and not as much needed as they once were, we'll basically be following a process that was defined by the Java SE folks for SE 6. It's a multi-step process that effectively means that something goes from being a required component of the platform to being an optional component, over multiple releases. First, we declare that some technology is a candidate for this type of pruning, and in the next release we might actually move it from the required state to the optional state.

There are a couple things we discussed pruning out. One of the bigger ones is JAX-RPC [JSR 101, Java APIs for XML-Based RPC]. It was an older technology that's effectively been replaced by JAX-WS [JSR 224, Java API for XML-Based Web Services], which is a better match for the Web services support we need.

The other thing is the whole EJB CMP [container-managed persistence] support, the entity bean support that's been there for a very long time. It had some issues, and wasn't getting quite as much traction as we might have liked, and effectively it's been now replaced by the Java Persistence API [JSR 220, Enterprise JavaBeans 3.0]. We think that's a much better approach to solving that same problem. So we don't think there is a great need for the EJB CMP support any more. Those are the two big things listed in the Java EE 6 JSR for pruning.

There are additional things we've been discussing in the expert group that may also end up in that category. One of them is the JAXR API [JSR 93, Java API for XML Registries 1.0], an API for accessing [Web service] registries. It's one of those things, again, that hasn't seen quite the use that we anticipated when we added it to the platform.

Our initial plan is to deliver the final Java EE 6 spec in the fourth quarter of 2008.

Frank Sommers: You said that the communities formed around non-Java EE enterprise technologies are one of your main inspirations for Java EE 6. Why do you think those communities formed outside of Java EE in the first place, and how do you plan to address their initial concerns about Java EE in version 6?

Bill Shannon: There are a lot of reasons those communities sprang up. One is that we have been so incredibly successful with Java EE, and that success both enabled the Java EE community and inspired people to consider competitors to that technology. So in part it's our success that enabled those communities.

In some cases people have looked at what we've done and they thought of better ways to do it. There is no one perfect, final answer to all programming problems. There are alternatives being considered. The incredible growth of the internet and the Web has inspired more and more people to develop applications for this environment, so there are lots of alternative ways of doing things. Even Java technology is not the only technology being used here. With the incredible range of applications being delivered, it's natural that there would be alternatives.

Frank Sommers: How do you view the role of the Java EE specification in a world where there are increasingly alternative technologies to accomplish the goals defined for Java EE?

Bill Shannon: Part of what we're trying to do in EE 6 is to embrace some of the alternatives by making it easier for people to choose which alternatives they want to use with, or on top of, the Java EE platform. The extensibility support that we'd like to add would help with that.

It's not always possible to support all the alternatives. Sometimes, you do have to make a choice. Where possible, we'd like to leave the choices in hands of the application developers. Different applications and different developers with different needs and backgrounds will prefer different alternatives.

Frank Sommers: Some emerging alternatives for enterprise development are not based on Java. To what extent will Java EE 6 embrace non-Java enterprise technologies?

Bill Shannon: There are a few ways we're looking at non-Java technologies. One way is interoperation with those non-Java technologies through Web services. That's a very core capability, and is very important to the platform. And it allows to connect Java and non-Java things together.

In addition, we're also looking at ways to add other, non-Java, language support to the Java platform. There are now a lot of things that will help you write your applications in different languages but still deliver them on the Java platform.

The JRuby work is now being done at Sun to deliver support for the Ruby language on the Java platform. There's the Groovy language, which is a JCP standard [JSR 241, The Groovy Programming Language]. Roberto Chinnici has been doing some experimental work to support JavaScript for Web applications. We'd like to enable more of those things to happen with Java EE.

Which of those we'll eventually bring into the platform and endorse as part of a standard, required part of the EE platform, that's not clear yet. We definitely want to enable that level of experimentation and some of those alternatives to be used in the context of Java EE applications.

Frank Sommers: To what extent do you see a room for "opinionated software" in the EE spec? By that, I mean the conscious decision to narrow down the choices developers can make in the interest of simplicity, or at least to guide developers toward a common development style. Are such decisions anathema to Java EE's desire to embrace all kinds of enterprise technologies and APIs?

Bill Shannon: What we're seeing now is developers increasingly embracing the notion of freedom of choice. Our original approach to J2EE and Java EE was that we'd make decisions that would define the one standard way of doing things, and we would then incorporate those decisions into the platform. Sometimes we got it right, and sometimes we didn't.

We're now moving to the world where there are so many choices available, and developers would generally prefer to have the choices in their hands rather than us making the choice for them.

You're right that things like Ruby on Rails, they made a lot of those choices for you, and forced you into a particular style and framework that, if you buy into that, gives you many benefits. But that does restrict some of your choices. We'd like to have some of the ease of development attributes of something like Ruby on Rails, but in an environment that doesn't restrict you to just that style of development.

Our goal with the Web profile, for example, is to define a class of products that are simpler than the full Java EE stack. The Web profile doesn't have all the capabilities of Java EE, but it has enough capabilities that you can build on for a wide range of simpler applications.

In the future, we could define additional profiles targeted at different needs. If your goal is to write applications for some telecommunications environment, for instance, we could define a profile that has the right collection of technologies for that type of application.

Frank Sommers: How do you see the role of vendors evolving in an enterprise Java world where developers have more and more choices, and where many of those choices come from open-source efforts?

Bill Shannon: Vendors will still have a very important role, because they are still the primary means for developers to get access to the platform's capabilities.

If you look at what the major vendors in this space are doing, most, if not all, of them, are approaching things similarly to what I described here: They are embracing some of the open-source and alternative platforms in their product lines. Some of them are supporting things like Spring in their Java EE products, for example. They're well-aligned with what we're doing in EE 6.

Frank Sommers: How will Java EE 6 make it easier for developers to compose an enterprise application from their choice of frameworks and components?

Roberto Chinnici: That's still in the early stages. From a developer's point of view, we'd like to see a pain-free way to use multiple frameworks, especially for Web applications. Thus far, developers have a hard time having to juggle the requirements of several frameworks in an application—Spring and Hibernate, WebWork, and things like that, especially when trying to mix them. The goal is to define a hassle-free way to use these together in an application.

Bill Shannon: Combining Web frameworks into a Web application usually requires that you pick up all the different pieces, and put them together, and then you have to edit this one descriptor that talks about everything and how all that fits together.

To figure out what to edit in that one descriptor to make all the pieces work together properly, is kind of a pain. Wouldn't it be nice if you could just pick up the pieces and drop them into your application, and they would combine in ways that you didn't have to describe, but would still make sense and would allow your application to work? That's the sort of simplicity we're aiming at.

Frank Sommers: What is the most important design lesson you've learned in your years as a key architect of Java EE? What do you consider to be the biggest design mistakes?

Bill Shannon: Everything is a compromise. That's what you learn. We're always trading off content and date and resources. Nothing we do is ever perfect, because if it was perfect, it would be late, and being late would make it not perfect.

If we had more time to do some of these things, we could have done a better job the first time around, but would also have been much more delayed, and that would have completely changed the market, and would have opened the door for other competitors to come in because we were moving too slowly. You just have to make the best decisions in the time you have. The timeline of the work you do is an important factor to consider.

This always leads to interesting discussions in the expert groups, where some people come in and say, Well, we want to be the absolutely best we can ever be, and we'll take as long as we can to do that. I think we need to balance that desire with the need to actually deliver something in a finite amount of time.

As for individual choices that we made, if you look at some of the things that are on the list for pruning, you might conclude that those were mistakes. That's not a fair characterization of them, however.

We included JAX-RPC in the platform, because Web services were becoming incredibly important, and we already felt that we were late in delivering Web services support in the Java platform. If we hadn't included that and took more time to come up with a more perfect version of that, the first version might have been wonderful. But it would have been so incredibly late that people would have concluded that Web services and Java EE were never going to come together. It was a tough trade-off.

EJB CMP is on our pruning list, too. That was pretty revolutionary stuff at the time we introduced it. I think we did the best job that we knew how to do at that time. There weren't a lot of better choices. Based on years of experience using that and trying alternatives, we discovered a better way to do things. Was it a mistake the first time around? No, I don't think it was a mistake, but over the years we learned things that allowed us to do that better.

Frank Sommers: Sun open-sourced its Java implementations over a year ago. How has open-source Java changed the evolution of Java EE?

Bill Shannon: We have Glassfish, which is the reference implementation for Java EE. It's been open-source for something like a year and half now, and I think we're just starting to see some of the changes as a result of that.

We're seeing more participation from the community, and from some of the other vendors as well in terms of contributing to the reference implementation. The extent that it opens the ability for other parties to contribute to the reference implementation is great, and it's no longer the case that Sun has to do the initial implementation work itself. We get other parties involved. We're definitely seeing that.

While it's still the case that most of the reference implementation is done by Sun employees, in the Glassfish project, we're seeing now some other companies delivering major components. Oracle is delivering the Java persistence component, and we're hoping that RedHat/JBoss will deliver the Web Beans technology, JSR 299, and we intend to include that in Java EE 6.

Also, if we do a good job of following the open-source model, we're delivering things to the community constantly, and getting feedback from them. That can't help but improve what we're doing.

Open-sourcing Java has changed Sun's role in different ways, too. We're definitely seeing improvement in our product, and in the perception of our product, related to Java EE 5 and the open-source work that we'd done. Glassfish is getting quite a bit of traction, and that's a core of our product—that is our product. Having an open-source application server opens a lot of new markets to us. The fact that it's the first one implementing the new Java EE standards helps us a lot, too. The open-source process definitely allowed us to build a much better product than what we had before.

Roberto Chinnici: I should add that many developers contribute by picking up the latest build from the open-source sites, and then kicking the tires. There are people who are passionate about an API, for example, and they would use that implementation and API, and identify issues and bugs. Even if they do not contribute code, that feedback truly makes the

Resources

JSR 316, Java Platform, Enterprise Edition 6 (Java EE 6) Specification

http://www.jcp.org/en/jsr/detail?id=316

Talk back!

Have an opinion? Readers have already posted 11 comments about this article. Why not add yours?

About the author

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.