1 2 3 Previous Next


33 posts

Goodbye! Blog

Posted by robc Apr 29, 2011

With the closing of the final approval ballot earlier today, it is now official: the JCP Executive Committee has given a green light to the release of the Java EE 6 platform specification. The final release will happen on December 10, when GlassFish v3 will be available. For more details of the ballot, with comments from several EC members, please refer to the JCP web site. Of course the excitement of the event drove me to watch live the ballot close at midnight PT and tweet about it!

Several other Java EE component JSRs were approved at the same time: Servlet 3.0, JPA 2.0, EJB 3.1, Connector 1.6, CDI 1.0. All other components, be they full JSRs or maintenance releases (MRs, for insiders), had been previously approved. I should also mention here that, being part of the platform JSR (JSR-316) the Java EE 6 Web Profile too was approved, and so was the Managed Beans 1.0 specification I talked about in prior blog entries. So, yes, now we really have profiles in Java EE: let's put them to good use!

We are going to have more white papers, tutorials, etc. coming up for the final release in a few days. In the meantime, even a casual perusal of the javadocs will show a number of new APIs in key areas: JAX-RS, Dependency Injection, CDI, Bean Validation. I see a bright future for these APIs, and fully expect them to become key components of Java EE applications in the coming years. I also happen to think that the level of integration that we achieved between these new APIs and some of the existing ones represents a valuable principle that can guide the evolution of Java EE going forward; certainly I expect future Java EE APIs to be held to the same strict criteria for integration with the rest of the platform that JAX-RS, Bean Validation and CDI were held to in this release.

It's been a long journey, so I'd like to take this opportunity to thank everybody who contributed to this release over the years, whatever form their contributions took. Naturally, one tends to focus on expert group members -- after all, they get the coveted (?) mention of their name in the specification itself in exchange for years of toil on the mailing list -- but with the continuous increase in the transparency of the process and the use of open source for the reference implementation, it turns out that there are many, many more contributors than the usual suspects. So, whether you sent feedback to the expert group, reported an issue in the implementation, asked a question on one of the GlassFish mailing lists that led us to realize we had overlooked something, or spoke to me at a conference or some other event to describe your experience with the technology and suggest improvements, please accept my most heartfelt thanks.

Now let's enjoy Java EE 6!

The Proposed Final Draft (PFD) of the Java EE 6 Platform specification and of the two other specs being defined by the JSR-316 expert group, the Java EE 6 Web Profile specification and the Managed Beans specification, is now available from the JCP web site.

The most important change since public review is that we have added JSR-330 (Dependency Injection for Java) and JSR-299 (CDI, Contexts and Dependency Injection for the Java EE Platform) as required components to the platform and the web profile, as I preannounced two months ago.

Attentive readers may have noticed that the Managed Beans specification is a new document; until now, JSR-316 had only produced two specifications. A natural question to ask at this point would be: "wait a minute, didn't we already have managed beans?" The answer is yes. We already had managed beans in JSF. We also had a notion of beans in CDI, one that encompassed plain beans (called "simple beans" in a draft of that specification) and EJB session beans. And of course EJB session beans can now be used outside of a Java EE application server, thanks to the introduction of EJB Lite. The platform expert group then agreed to put things in order and came up with a unified notion of a managed bean that could serve as a foundation for all the kinds of "beans" floating around in the platform, and more generally as a way to unify all the existing component models going forward.

For this plan to work, the definition of a managed bean must be sufficiently general to let different specifications build on it, and at the same time be meaningful enough to be usable in a practical way by developers. At the core, a managed bean is simply a Java class that is treated as a managed component by the container: It can have an optional name, and it can take advantage of a small, predefined number of services in Java EE, mostly related to lifecycle and resource injection (@PostConstruct, @PreDestroy, @Resource, ...). Other specifications can build on this basic definitions and add other services. So for example CDI adds interceptors, dependency injection (@Inject), scopes, etc. We also re-interpreted EJB session beans as being managed beans with added services, such as transactions, security, instance pooling, remoting, etc. Finally, we made it possible for most existing components in the platform to be managed beans, or, as I will explain below, for managed beans to be used as components of any given type.

Let me elaborate on this last point through an example. Given a JAX-RS resource class, you can turn it into a managed bean by adding a @ManagedBean annotation, or an EJB component annotation (@Stateful) or one of many potential CDI annotations (e.g. the @Default qualifier). What's more, one can also take the opposite view, and see the resulting class as coming from a managed bean or an EJB component that has been turned into a JAX-RS resource class by the addition of a JAX-RS @Path annotation. The same thing can be done with a servlet, or a JAX-WS endpoint class, or (mostly) any other component type in Java EE 6.

At a high level, the direction we're going in is one where the services made available by EE containers can be mixed and matched on any single bean, breaking down any rigid barriers, such as the traditional one between the "EJB world" and the "web world". In this respect, the newfound ability to define EJB component directly inside a web application can be seen simply as a way to let developers use managed beans of the EJB flavor inside the web container. Incidentally, I'm not claiming that we broke down every barrier and made available all container services to all beans yet -- some of that work will necessarily happen in a future release, especially in light of the compatibility issues that some of this mixing-and-matching can raise -- but I think that we delivered some genuine improvements to the model, all while operating a conceptual simplification of the platform and setting a strong direction going forward.

There are several other notable features in the PFDs: we introduced the new java:global, java:app, and java:module namespaces to go along the good old java:comp; we added Bean Validation 1.0 as a required component to both the full platform and the Web Profile, and made Validator and ValidatorFactory objects injectable using @Resource; we made it possible to portably declare resources of type DataSource either in code or via a deployment descriptor; we updated the versions of several other components to the latest ones (e.g. EL, JACC).

I'm looking forward to your comments on the draft. Please address them to javaee-spec-feedback<at>sun.com.

One big topic of discussion at JavaOne was the recently filed JSR-330, "Dependency injection for Java". As many of the comments during the JSR approval ballot made clear, some alignment of JSR-330 and JSR-299 (formerly knows as "Web Beans") was in order. What would be the point of having a JSR to help reduce fragmentation in the dependency injection space, if we end up with competing/diverging solutions in the Java enterprise space?

I'm happy to announce that, thanks to the work of many individuals, we've come to a positive resolution on this issue. Here are the key points:

  • JSR-299 will be updated to use the JSR-330 annotations
  • The initial draft of JSR-330 has evolved to take into account requirements coming from JSR-299
  • Both JSRs will be part of the Java EE 6 Platform

Normally, we would not be too happy (That's putting it too kindly! -- Eds.) about adding a new JSR to the platform so close to our planned release date, at a time when all other components JSRs are already in Proposed Final Draft. But, in this specific case, we are actually very happy to do so, because we think that the benefits for developers of having a single foundation for dependency injection in the Java platform, and a single way to use it in Java EE 6, are overwhelming.

So as to limit the impact on the schedule for Java EE 6, the JSR-330 expert group has kindly agreed to run at full speed through the process. The early draft of JSR-330 is already available on the JCP site. Barring last-minute changes, this is the version of the specification that we expect to go final as soon as the remaining stages in the Java Community Process run their course. For mathematically inclined readers, that's 74 days since the posting of the early draft, at a minimum.

We expect an updated draft of JSR-299 to be ready soon. I'll post an update when that happens. The changes to 299 are quite easy to picture: binding types are now qualifiers, @Inject must decorate injection points, etc.

Overall, we expect these changes to add four-six weeks to the schedule for Java EE 6. That would put the final release some time in November.

I'll give more updates on how we expect @Inject to work in Java EE 6 soon. I'll also talk about one of the ways that we have been going about reconciling the work in JSR-299 with the rest of the platform, namely the definition of a platform-wide notion of "managed beans". Stay tuned!


JavaOne 2009 Blog

Posted by robc May 30, 2009

JavaOne 2008 conference attendees and loyal readers of my blog may remember the first edition of the Script Bowl. In it, representatives of four scripting languages vied to get the most votes from the audience by extolling the virtues of their creations, all while avoiding getting incinerated by the scathing comments from the highly combustible judges. (Just kidding, it was all very civilized.)

Well, we're doing it again this year! It's session PAN-5348, "Script Bowl 2009: A Scripting Languages Shootout". This year, we have representatives from five communities: Tom Enebo (JRuby), Rich Hickey (Clojure), Guillaume Laforge (Groovy), Martin Odersky (Scala), Frank Wierzbicki (Jython). Before I get any hate mail, I should state that we're using the term "scripting language" loosely; mostly, we like the name "Script Bowl" better than "Languages-other-than-Java-on-the-JVM Bowl", so don't read too much into it.

With the increase of participants to five, we had to cut down the number of rounds from three to two. The two rounds are: one assigned task, with the participants showing how their language makes it faster/easier/better to carry out the assignment, and one free task in which they can highlight any cool features/apps they want. We fully expect panelists to enlist their respective communities to help with these tasks ahead of the conference. After all, the enthusiasm and competence of its community are essential ingredients in making a programming language successful.

This brings me to the goal of this blog entry. Last year we had as an assigned task writing a Twitter client -- we like to think we anticipated the fad of writing Twitter clients in all possible languages and platforms by a month or two. This year, I'd like to poll my blog's audience to suggest tasks: if you think you have an idea for a task for our panelists, just leave a comment on this blog entry in the next couple of weeks.

To help with the submissions, here are a few tips: first of all, panelists will only have about five minutes each to show their solutions to the audience. Ideally, we'd like something that the audience knows already or that can be explained very quickly, so as to leave as much time as possible to go over the specifics of each solution. Naturally, the task should be relevant to present-day programming: if you had to decide which of the five languages to use for your next project, what would impress you the most? Finally, it'd be nice for the task to leave room to showcase some cool/advanced functionality and yet be unbiased to any specific language.

Please leave your suggestions as comments and help us make the Script Bowl 2009 informative and entertaining for the audience. I hope to see you at JavaOne in June!

In case you missed the news, JAX-RS 1.0 (JSR-311) was the first specification scheduled for inclusion in Java EE 6 to reach the final stage. My thanks to the spec leads, Marc Hadley and Paul Sandoz, the entire expert group and the very active community around JAX-RS for making this happen!

I'd like to take this opportunity to advertise the schedule for the rest of the platform.

We plan to have all the component JSRs publish a Public Draft in October. EJB 3.1 did so yesterday and the other ones will follow soon. We also have an Early Draft of the Java EE 6 Platform specification ready to go out any day now (we are waiting for licensing and staging to happen), including the first draft of the rules that will govern all Java EE profiles going forward. Public draft reviews last 30 days and culminate in a ballot taken by the JCP Executive Committee for SE/EE.

The next stage for all the specifications is Proposed Final Draft, which we intend to reach by mid-December. At that point, the bulk of the specification work will be done and implementations will have time to catch up. We then have a few months to exercise the new APIs and complete the TCK work. The final release of the platform would then happen in time for JavaOne 2009.

Given the short time between Public Draft and Proposed Final Draft, I'd like to invite you all to read the specifications as soon as they become available and to send feedback to the respective expert groups right away.

In addition to the Java EE 6 talks, there are a few more events on my calendar for the week of JavaOne.

On Sunday, when I'm not caught up in rehearsals and last-minute slide editing, I'll check out the GlassFish Unconference and party. Since the agenda is entirely up to participants, bring your best topics and suggestions!

On Monday, I'll be at CommunityOne. As Tim Bray pointed out, it's free and packed with great talks, so you'd be crazy to spend the day elsewhere.

On Tuesday at 3:20pm I'm doing a session on "JavaScript: The Language Everybody Loves to Hate" (TS-4986).

In this talk I'll try to convince a predictably skeptical audience that JavaScript is a real programming language. I'll focus on functional and object-oriented programming, explaining all the arcana. The samples I'll show are mostly taken from popular frameworks, like jQuery, Prototype and jMaki. I'll also touch on some smaller topics, like modules and fluid interfaces. The focus is not on Ajax programming, so I will not cover browser differences or DOM at all, just core language concepts and how they scale. By the way, as I prepared the slides I thought of expanding this material into a series of blog entries. If you are interested, please leave a comment.

On Wednesday at 9:30am I'll be at "The Script Bowl: A Rapid-Fire Comparison of Scripting Languages" (PAN-5435).

Somehow I got persuaded to act as a judge in this American Idol-like elimination show. I'll try to keep my snide remarks to a minimum and I promise not to try and affect a British accent. Charles Nutter broke the embargo on the super-secret list of tasks that our panelists have been asked to perform. But he may have got the list of participants wrong: we will have JRuby, Jython, Groovy and Scala representatives on stage, ready to dazzle the audience with their best work.

In the rocket science department, on Wednesday at 2:40pm I'm registered to attend a session on "Transactional Memory in Java Based Systems" (TS-6316). A bit dry maybe, but ten five years from now this stuff is going to be everywhere, so you may just as well learn about it today.

On Friday, at 12:10pm I'll attend Kohsuke Kawaguchi's Hudson talk (TS-6547) to pay homage to this irreplaceable tool and its   equally irreplaceable author. I think that without Hudson all software development around here would stop; furthermore, at the rate it's spreading Hudson will soon run the entire software industry. Not too shabby for a butler!

Finally, after much session and party attendance, I plan to end the week on Saturday at the Scala Lift-off unconference (no ties to JavaOne). Right now I'm more interested in Scala than the lift web framework, but in any case it's going to be a great opportunity to meet other Scala-heads.

Overall it looks like a great (and exhausting) week in the making!


Java EE 6 at JavaOne Blog

Posted by robc Apr 24, 2008

JavaOne 2008 is around the corner, so I thought I'd compile a list of sessions touching on Java EE 6 technologies.

Let's start with the platform itself.

As part of the Sun Technical General Session (Tuesday, 1:30pm) I'll be giving an overview on EE 6 and show some cool GlassFish V3 demos. Then you are all invited to the  Java EE 6 Platform Community BOF (BOF-4984, Wednesday, 7:30pm) to talk about profiles and other features in the platform. Several expert group members will be there (12, at last count) and we are looking forward to a very interactive conversation with the audience.

Moving on to the main EE 6 components, here is a list of talks by the various spec leads:

  • TS-5343 EJB 3.1 (Tuesday, 12:10pm)
  • TS-5509 JPA 2.0 (Wednesday, 1:30pm)
  • TS-5415 Servlet 3.0 (Thursday, 10:50am)
  • TS-5425 JAX-RS 1.0 (Tuesday, 12:10pm and Friday, 2:50pm)
  • TS-5979 JSF 2.0 (Thursday, 2:50pm)
  • TS-5286 WebBeans 1.0 (Wednesday 10:50am)

(I just noticed the overlap between the EJB and JAX-RS talks. I wonder if it's too late to move one of them, or schedule a repeat session. I'll check with the conference organizers.) Update: The JAX-RS talk will be repeated on Friday at 2:50pm.

I would also recommend the session on JSR-303 (Bean Validation, TS-5616), which we are tracking closely for inclusion in the platform.

Finally, here are the community discussion BOFs:

  • BOF-5624 Connector Architecture 1.6
  • BOF-5039 JDBC 4.1
  • BOF-5753 EJB 3.1

If you like the demos I'll show during the keynote, you owe it to yourself to attend the GlassFish V3 session (TS-5921, Tuesday 4:40pm).


Extensibility and modularity Blog

Posted by robc Mar 17, 2008

Thanks to everyone who left comments on my previous blog entry on profiles, as well as on the related TSS and InfoQ articles. Also to the 700+ folks who voted on the poll on java.net or commented on it either on-site or on TSS.

At a high level, I have to say that the feedback reflects quite closely the discussion in the JSR-316 EG. Perhaps the EG composition is even more representative of the whole community than we originally thought!

Unfortunately, the poll results are a masterpiece of indecision: large preference for including JSF 2.0 and WebBeans 1.0, but short of a majority (46.7%). A smaller profile without JSF and WebBeans at 28.9%, but even that camp is split nicely in two (at 17% and 11.9%). A full 24.2% of respondents who don't care.

Conclusion #1: There is strong demand for JSF 2.0 and WebBeans 1.0.

Conclusion #2: We cannot please everyone (we kind of knew that).

Having read all the comments, there seems to be a bit of confusion about the way that extensibility would work. In my original blog post I didn't go in depth into it, mostly to avoid breaking the record for the longest and most boring blog entry on java.net, but the subject deserves a few more words.

For clarity, I find it convenient to distinguish two cases, based on whether a technology can be added to an application by a user or by a server vendor. I will reserve the term "extensibility" for the first case, and use "modularity" for the latter.


At first sight, making it possible to add any technology via extensibility seems desirable. (Incidentally, this may well be the Spring tack on the whole thing.) In reality, this would require a lot of contracts to be standardized. Since standardization has a cost and the returns would be diminishing, I doubt that it will ever cover 100% of the functionality. Performance-wise, going through standard contracts at this level of granularity may turn out to be sub-optimal, so I imagine there'd always be an incentive for vendors to bundle the implementation of certain APIs with their application server to try and squeeze every bit of performance out of it.

At the same time, extensibility is a great thing if it captures the 20% of functionality that covers 80% of the needs, thus enabling a lot of developers to painlessly use a lot of technologies at essentially no cost in complexity or performance. In essence, this is the reasoning behind making extensibility in the web container a key goal for Java EE 6.

A lot of the APIs we've been considering for the Web Profile can be handled via extensibility: drop one jar into the WEB-INF/lib directory of your application (or in some suitable shared directory on your server) and you get JAX-RS, or JSF, or JPA, or WebBeans, or server-side JAX-WS, or... The key factors here are the availability of the technology in standalone form (which requires a separate TCK to exist) and the adequacy of the extensibility contracts in the servlet container. We certainly want to make sure that the latter are sufficient to plug in pretty much any web framework worth using, so please keep an eye on the Servlet 3.0 developments and let us know if you find any holes. On the TCK front, we are resource-constrained on what we can do with respect to existing technologies, but for new ones (including all the ones listed earlier) we will make sure suitable TCKs exist.


The second case, modularity, covers pretty much everything else. In a number of cases, which hopefully will get smaller over time, there is no independent TCK for a technology, so an implementation cannot consist a jar separate from a full Java EE server. In some other cases, there is no standard contract that would enable you to plug an arbitrary implementation into an application server. (EJB 3.1 is a good example.) Designing these contracts is non-trivial, so we need to accept as a fact of life that we won't have them in Java EE 6. Luckily, we got a bunch of new contracts done recently, e.g. the security-related ones in JSR-115 and JSR-196, so things are moving in the right direction.

As part of the work on profiles, we've been trying to improve on the situation as much as time and resources allow. In the case of EJB, we've been prodding the EJB EG to define a "lite" subset of EJB 3.1 which can be run on top of the Web Profile. This way, application server vendors will be able to offer a "EJB 3.1 Lite" implementation in their Web Profile products even if we went with a "small" Web Profile (e.g. option (A) in my previous blog entry).

So, why am I using the word "modularity" for this case? It's because it fits well with the trend we are seeing towards more modular application servers like GlassFish V3. Rather than having a monolithic server, you'd be running a small core and an initial set of containers, with some baseline functionality. You could then download/install/activate as needed any number of new modules providing additional functionality, like EJB 3.1 Lite. Of course, you could handle this way modules that use extensibility too, especially when they are shared by multiple applications, but for things like EJB 3.1 Lite there literally wouldn't be another option: absent an SPI, the choice of what EJB 3.1 Lite implementation you run would be limited by what your server vendor offers.

Reality bites

Once you look more closely at the different APIs, you start realizing that there are some "gray" cases too, like JPA. In fact, although it's possible to add JPA to a web application via extensibility, your application will be restricted to using the SE-based programming model (i.e. using the javax.persistence.Persistence class as an entry point). Enabling the resource injection-based EE model is non-trivial and would require quite a bit of work. Is the SE model good enough? Does extensibility have to go all the way in all cases? I hope not, but it will take time to figure out where to draw the line for maximum effectiveness.

As a coda, I should talk briefly about JAX-WS. It wasn't very clear in my previous entry, but since Java EE 6 requires Java SE 6, the JAXB and JAX-WS APIs would be present in *any* profile. Unfortunately, what's left out is the ability to define web service endpoints on EE, which traditionally follows the JSR-109 model. We'd like to see this case handled via extensibility, so that it'd be possible to drop a "server-side JAX-WS" jar into WEB-INF/lib and have the application work in any servlet container, especially those that don't support JSR-109. In this case, we'd also like this extension library to use the version of JAX-WS that comes with the JDK. Currently there are some missing bits in the JAX-WS API that prevent this from working, but we're looking into adding a small SPI for this purpose to the JAX-WS 2.2 release.

Filter Blog

By date: