In terms of developer adoption, it’s been a huge success. We’ve seen a lot of people downloading GlassFish, which obviously is [for] the purpose of trying it, trying the new features and there is a fair number of new JSRs that can map in Java EE 6 which have been fueling this demand. I’m thinking in particular to the JAX-RS, the REST implementation for Java, as well as CDI for the components. These two JSRs have really been driving a lot of the adoption and we’ve seen multi-millions downloads of the reference implementation. Then we’ve seen also adoptions in terms of the other applications servers - JBoss has released also a web profile compatible implementation and we know for a fact that IBM and Oracle, the WebLogic product, are working hard towards a certification of their product with the Java EE 6 platform.
This is the normal pattern: we will see the developers first and then the products coming after. It’s been better than before actually. We see a better adoption than we’ve seen in the past with the previous releases of the Java EE platform.
In terms of spec, yes. I think it was very important to prove that the Java EE specifications as a rule were so well written that we could suddenly decide that we could take a subset of it and still remain compatible within that subset. Applications that were developed in the Java EE 5 platform that were using the web stack, say servlet plus maybe JSF, worked completely unchanged if you were to use the Java EE 6 Web Profile platform. I thought that worked very well, that was a success to be able to drive two different profiles within the same specification release. All that I would say was a big success. In terms of how people reacted to the actual implementation of these platforms, it has been more of a challenge.
It seems that most of the people have been complaining for a long time that Java EE was too big and they didn’t need all these features, and all these criticism we got, but then when we provided them the Web Profile, which was about 20 MB smaller than the Full Profile, we still saw that they’d mainly downloaded only the Full Profile. So, in terms of downloads, it is true that we cannot say that there has been a lot of pick up. Maybe it was partly our fault because in GlassFish, for instance, we decided that even though you wanted the Web Profile, you still retained all the features of the GlassFish application server. In particular you would have the console, you would have the clustering, you would have all these things being available even in the Web Profile, which obviously is growing the image that you will download. Maybe it would have been more interesting for the people to have a slimmer Web Profile in terms of implementation. Maybe it would have been interesting in the spec world to have a slimmer Web Profile where you would have started removing even more specifications than what we’ve done.
It’s a mixed bag, to be honest. It’s a success on the specification side, but on the product side so far I cannot say that people have been really picking it up. They seem to be happy maybe because we are so modular and we load the features only on demand. The fact that you download the Full Profile, well if you never use CORBA, if you never use the remote EJBs we’ll never load it anyway, so you don’t really care if it’s on the disk; it’s never going to be on memory. Maybe that was enough for people.
3. Are there any plans to add any other profiles to the platform?
From Oracle I don’t think there is at this point, but the way profiles work is, like anything else in the JCP world, by filing a JSR. So it’s really an open process and I believe anyone could file a JSR, as long as you’ve got enough of the community support, enough of the Executive Committee support from the JCP, anyone could file different profiles. We’ve been talking over the years about potential candidates. The obvious candidates ... a communication profile have been put on the table many times to have something that would be capable of running a SIP servlet container. There have been also rumors of a Portal Profile, but nothing has been materialized yet, as I said. It’s just a matter for the people to file JSRs and be able to move them through the JCP process.
It depends. If you take the programming API, it won’t be very different because Java EE for many years has had the ability to clearly define how to export services and how to consume services. As long as we’ve got this indirection in place, how these resources will be procured by the system is really independent of how they will be actually injected into the application. I would think in terms of the API - very, very little change. How the deployment of those applications will happen will be very different, because we will basically take upon a lot of the tasks that were done by the deployer, the role that we usually call the "deployer role" in the Java EE platform, which is the guy responsible for configuring the application server with the different resources - maybe to attach to a database or maybe to attach to a remote MQ service and have the resource, which I was talking about, of the application being bound to those particular definitions in the application server.
Any particular administration tasks that were to happen before the deployment were very specific to a particular application server. They were usually non-portable, they were admin commands that you had to run, which of course would be very different across the different implementations of a Java EE application server. What will happen in the Cloud is that the Cloud application itself will say, "I require an MQ service. I require a database service." And it will be the responsibility of the Cloud provider to instantiate those services, most likely in different virtual machines, and have them being bound, correctly, within the application server and then in the application.
So basically, the deployment will become much, much simpler; it will become just deploying an application that will define explicitly, or maybe implicitly, their resources requirement, that they require a database - and that could be explicit; just because they use JPA, they obviously require a database, so this could be an implicit resource. But whether they find them explicitly or implicitly, it would be the job of the application server to provide and to fulfill those requirements and that will simplify a lot of the job of the Java EE deployer. He will just have to basically deploy and undeploy things.
Yes, I think it’s a good idea because it’s a natural fit. Is it the only place where we could do it? - No! I think that it’s something that the JCP and the JSR leads should certainly think about. I don’t have a strong opinion myself of where it should be implemented. As you said, I think it’s a good idea in the JAX-RS because it’s a natural fit. This is how you could potentially provide this MVC framework, but I don’t think it’s limited to JAX-RS.
We are hoping so, in particular for WebSockets. There has been some activity that has been going on for more than 2 years, I think, in terms of WebSockets implementation in the Grizzly community, which is one of the sub-open-source projects of GlassFish, and that is providing an implementation of a WebSocket protocol. Obviously, this is non-portable and it’s using some private APIs, but we are hoping to leverage that work and standardize it in Java EE 7. That’s one of the dimensions. For HTML5, the first natural place where we are going to implement some of these features is JSF, obviously. We are going to provide some JSF enablement for HTML5 in the platform. It’s already been filed in the JSR, so there is no doubt that it is going to come in the next release of the Java EE platform.
Yes. And that’s another item on the wish list of things that we would like to do. I don’t think there is a strong commitment yet. I actually believe that we’re requesting help from external people to be able to deliver such a JSR, but basically yes, we would like to have the ability to map the Java components to non-relational database. There are two school of thoughts: whether or not we could adapt the JPS APIs to be able to talk to a NoSQL database is one of them; or to come up with a completely new set of APIs. It’s unclear at this point if the first option is actually doable because there’s a strong attachment of the JPA APIs to an SQL database backend, so it’s unclear if we’ll be able to steer them into this new direction without making them incompatible - that’s certainly not something we want.
Therefore, it might be necessary to come up with a new set of APIs. I think these are the questions that we are asking ourselves and that the community is starting to look into. I hope that we’ll be able to come to a solution in time for Java EE 7.
10. Will we see a standard for caching - a sort of ‘Son of JCache’?
There has been a JSR for many years, which unfortunately has been dormant for many years, but with these new technologies that came up with the new web technologies I think the caching is becoming a lot more important again. So, we are hoping to revive that JSR and then I think there is a very strong commitment from Oracle to do that. I believe that a new Expert Group will be formed to continue on the work that was done before from Oracle, because they were the spec lead at the time, and provide a release of this JSR for the Java EE 7.
The batch, yes. For the batch there is definitely again internal talks and I think that there will be a JSR filed around batch processing. They hope so far that it will be finished in time for Java EE 7, but it’s a rather new technology, so we’ll have to see if that can be done. But I think it is doable. I believe that, if we can manage the feature set, we would be able to deliver it for Java EE 7 so I’m pretty optimistic as well. So that’s definitely a "Yes" for batching. The other items, it’s unclear at this point, but this is the JCP and I don’t think people should look at Oracle as being the sole provider of JSRs. Anyone should come up and file JSRs. I think it’s one of the good things that the JCP is offering.
12. How does modularity fit into Java EE 7?
Ah yes, modularity; it’s been a favorite subject for many people for many years. It’s pretty obvious that as the Java EE platform is evolving, we always rely on the Java SE platform to build upon. Modularity will most likely not be different in that regard, that we are going to rely on the solution that is being offered by Java SE to be able to build upon it. As you probably know by now, the modularity is not going to be delivered in Java SE 7, but in SE 8. What that tells me is that modularity will not be available in the platform before Java EE 8; so not in Java EE 7, but in 8.
Now, will we see absolutely no modularity feature in Java EE 7? - it isn’t clear at this point. I think that there will be some features, certainly better packaging, maybe some preparation work, the ability to version applications will maybe also be part of the Java EE 7 specifications. But in general, modularity has been implemented by most of the Java EE application servers, so most of them are actually modular application servers and do offer some sort of modularity, most of the time through OSGi.
For the people who are actually desperate about modularity of applications... We have multiple examples of people deploying applications which are actually bigger than the application server, much bigger, so they really do have issues with modules. Sometimes unfortunately they have several instances of these applications and they have shared components, which they cannot share because obviously the application server model is not about sharing class loading. Each of the application servers have provided different features which are unfortunately not portable, but have provided features where you can start using common libraries and reference those libraries when you deploy and stuff like that.
GlassFish is a little bit ahead of all those in that particular domain because we have even the ability to deploy what we call "hybrid applications" which basically are Java EE applications but packaged as OSGi modules, where you can reference OSGi modules from your Java EE module and you can deploy them. They are using the normal Java EE APIs; there is nothing too specific in that regard. Obviously we can’t guarantee that this will be easily portable to a future Java EE 8 modularity solution, but it’s certainly something that people can start using and if they keep the usage of the feature set limited, I would think that it would be easy for them to move to another modularity solution when it comes up.
So, the answer, unfortunately, is not very good; it’s not going to come very soon. But I think that for the people who really need modularity today, there are solutions available in most of the application servers out there, so it’s something that they should start leveraging if they need to.
Yes and no. As the GlassFish architect when I started looking into how can we modularize 60 MB of JAR files, which was the application server, I obviously looked into OSGi. I realized some of that complexity that OSGi was putting upon the programmer, I thought that was a good model, but it was also a difficult model to program against. And so we put in place an abstraction layer so that GlassFish itself is not necessarily dependent on the OSGi APIs. That abstraction layer can be then implemented in various flavors, and we so far have two implementations. But it’s not inconceivable that we could have a third implementation that would be based on the Java SE modularity and then suddenly have all of the modules running correctly. It’s a bit of a wishful thinking that we are going to be able to just do it like that, but there’s a hope at least.
If it doesn’t work, or if we don’t want to do it anyway, I think that in the worst case that’s going to happen, you will have two modularity solutions that will not really talk to each other unfortunately. Just like we have today the OSGi world that lives on top of the JDK and gives some visibility of what you can load from the JDK, these are two worlds which don’t really communicate well with each other. I think it might be a situation that will continue for many years, if these two entities do not converge on a single solution.
14. Will Java EE 7 require Java SE 7?
Yes; this is usually how we do the platforms. We always require the latest Java SE platform.
You are probably mentioning the Coin projects. I don’t think we are going to leverage any of these in terms of the Java APIs. Obviously, we’ll be happy to use that and people would be happy to use that when they develop their Java EE components, but I don’t think we’re going to leverage any of that in the Java EE 7. I think that some of the language changes that we would like to see coming, as for instance the ability to define properties - the ability to not have to have all this dancing around with defining the property as a field, and the setters and the getters, and the ability to get notified when there is changing. We have all this code, which is a lot of code that you have to write; even though most of the ideas help you, it’s still code that is cluttering your vision when you look at the source code.
For us, the next step would be more into this type of how we could provide some of the constructs that we’ve used to build these Java EE components back into the language. And properties is probably the number one item that we can see having values. I think until we see these, we will use some of the language features like we’ve used them so far, but I don’t think we will be really changing the programming model to leverage those.
16. What’s the timeline for EE 7?
The timeline is 2012. It’s an aggressive timeline, it’s next year. And that’s why we are going to try to have a fairly small set of feature changes compared to what we used to do in the past where Java EE 5 and Java EE 6 had a lot of changes. That obviously took its toll in terms of how long it took us to deliver those. So the next release we are really going to try to become a bit leaner in terms of feature set. A bit like what JDK has been doing with the OpenJDK 7 and OpenJDK 8 where they said, "There’s all the features that we’d like to do and depending on how you are going to deliver, you are going to fall into one bucket or another." So far that’s what we’re going to try to do: to limit the bucket of the Java EE 7 so that we can deliver next year.