1 2 3 Previous Next

robc

33 posts
robc

Goodbye! Blog

Posted by robc Apr 29, 2011

So as not to leave this blog dangling, I thought I'd post a notice here too besides the now customary tweet.

I have decided to pursue another opportunity, so today is my last day at Oracle.

As a bit of history, I joined JavaSoft back in 1997 to work on the first version of EJB and what later became J2EE / Java EE. It's been a long ride and I'm very happy with all that we accomplished (five releases, with a sixth in the making), but it's now time for me to move on.

 

Thanks to all the readers of this blog over the years. I won't be posting here any more going forward. I did create a new blog which may or may not see some use, depending on the amount of free time I have and my inclination to write.

Thanks and best of luck to everyone!

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 downevery 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, andjava:module namespaces to go along the good oldjava: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 ballotmade 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 availableon 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!

We are in the process of updating the training and certification materials for Java EE 6.

We've done the first part of the job in collecting and analyzing the tasks that a Java EE developer may be expected to perform as part of his/her duties. Now we'd like to solicit feedback from developers to help us validate this material.

For this purpose, we created five surveys, one per technology area (JSF, Servlets & JSP, Web Services, JPA, EJB). We'd much appreciate if you could go take one or more of the surveys, as appropriate for your experience.

There is no need to log in, but we'd appreciate being able to contact you for any follow-ups.

The survey is remarkably short and compact. You just need to tell us how often you are asked to perform certain tasks, how difficult you find them to be, how important they are for your job and how much training you think is required to learn to perform them. You can also provide us with comments on any objectives you would like to see added or removed from the list of objectives.

The deadline for the survey is July 31st, so please take a minute to do them today. Also, please tell other developers you may know (coworkers, friends, etc.). The broader the response we get, the better tuned the resulting training and certification materials will be.

I put the slides for my technical session at JavaOne online here. The session is: TS-3802, Functional and Object-oriented Programming in the JavaScript Programming Language. The repetition of the word "programming" is entirely due to lawyer intervention, I should note. Also, the formatting is slightly different from the one I used at the conference, due to the various conversions involved. I've also fixed a few typos/bugs.

robc

JavaOne 2009 Blog

Posted by robc May 30, 2009

http://java.sun.com/javaone/2009/images/09J1_Web_Header_800x108.gif

Once again, we are at the crazy weekend before JavaOne. This year Arun interviewed me and, more importantly, provided a link to my sessions at JavaOne. So I won't provide any detailed directions here, and instead summarize my speaking engagements for the week.

After watching the morning keynote on Tuesday, I'll be the lone (!) judge (!!) on this edition of the Script Bowl (PAN-5348). If you attended last year, you'll know that "judging" entails making semi-informed comments on what you just saw, without the benefit of any advance screening of any kind. This year, standing on my lonely perch, I'll be A Judging Army Of One, in effect the programming alter egos of Randy, Paula and Simon, all frighteningly woven together in one entity. It will be fun: Clojure, Groovy, JRuby, Jython and Scala, all in one hour!

A few hours later, hopefully having recovered my sanity by then, I'll give an update on Java EE 6 during the afternoon technical general session. This year the lucky winner of the demo lottery wasLudo(vic) Champenois. He tried hard to get himself disqualified for the job by posting the the worst ever Java EE 6 blog, but it didn't work out. So come to the general session ready to see the latest in NetBeans and Eclipse tooling for GlassFish v3.

Once you've learned more about the Java EE 6 platform and attended a myriad of sessions on the various technologies that it contains, please come to our community BOF on Wednesday night (BOF-4483) and ask the hard questions. We'll have a good number of members of the platform expert group on hand to give you a varied perspective on the decisions that were made over the course of JSR-316.

Finally, for my fellow JavaScript-ers, I've updated last year's session on the world's most hated language to cover functional programming in more depth. You are invited to come to TS-3802 on Wednesday afternoon and learn more about the assembly language of the web, now faster than ever.

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!

It is my pleasure to announce that yesterday we published on theJCP web site the public draft of the Java EE 6 Platform specification. The review will last 30 days, ending on February 23. The email address for feedback hasn't changed: it'sjavaee-spec-feedback<at>sun.com.

One JSR, Two Specifications

The first surprise when you downloadthe specification is that there are two documents: in addition to the platform specification, we are publishing for the first time the Web Profile specification.

The "meat" of the specification is the list of component technologies, which I'll get to in a second. First, I'd like to draw your attention to chapter WP.1. Since the Web Profile is the first profile in the history of the Java EE platform, we thought of including some background material. In addition to a description of the class of applications that the profile targets, we also included a fairly general discussion on how to determine which requirements are applicable to a given profile. In general, this is not a trivial operation, since there are many sources of requirements and many allowed combinations of technologies. We hope that definers, implementors and users of present and future profiles will all benefit from these clarifications. Before diving into this material, please make sure to read chapter EE.9 of the platform spec, which contains the general rules that all profiles must follow.

Web Profile

After much deliberation, the platform expert group chose to go with a mid-range version of the Web Profile, close to option B in my earlier writeup.

The required technologies are:

   
Servlet 3.0
JSP 2.2
EL 1.2
Debugging support for other languages (JSR-45) 1.0
JSTL 1.2
JSF 2.0
JSR-250 1.1
EJB 3.1 Lite
JTA 1.1
JPA 2.0


 

You may notice that some of the version numbers don't match the latest published API (e.g. EL 1.2). That's because we plan on making minor changes to the corresponding technology via a maintenance review. I'll be providing more details as they become available.

What about JAX-RS?

JAX-RS is not a required component of the Web Profile. The expert group concluded that it is too early to mandate the inclusion of JAX-RS, given that not every web application out there is going to expose a web API to its users. As the popularity of JAX-RS grows, we may include it in a future version of the Web Profile. In the meantime, JAX-RS will be fully pluggable in all Servlet 3.0 containers, hence in all Web Profile products. And of course JAX-RS is a required component of the full Java EE 6 Platform. (For a a description of the pluggability mechanism, please refer to chapter 8 of the servlet spec. The servlet expert group is still working on some of the details, which will appear in the upcoming proposed final draft.)

What about Web Beans?

Web Beans is not listed as a required component either in the Web Profile or the full platform. On the other hand, it is mentioned in section EE.6.29 as a component under consideration for inclusion. The expert group would like to solicit feedback from the community on this subject.

Observant readers will also have noticed that the Web Beans specification, currently in public draft, was extensively updated just yesterday. Gavin King's blog has all the details of the changes, which were triggered by feedback mostly coming from the JSR-316 expert group. Among the biggest changes, the term "Web Beans" itself has disappeared from the spec. While this may come as a shock to some, it's really a positive development, since it signifies the merging of the functionality that Web Beans provided with the established Java EE concepts of "containers" and "components". I believe that the end result is a more usable, better integrated, easier to learn "Web Beans", now providing contextual support and dependency injection for the whole Java EE platform.

What about Bean Validation (JSR-303)?

Even more observant readers will have noticed that JSR-303 is in public review, yet it is not listed as a Java EE 6 component JSR. This is simply a matter of timing; the platform expert group just started discussing the inclusion of JSR-303, so no decision had been reached at the time the public draft of the platform specification was sent to the (virtual) presses. I should point out that the JSR-303 expert group, lead by Emmanuel Bernard, has done a lot of work to address the needs of JPA and JSF in the area of validation, so I'm confident that JSR-303 will be well received by the community.

What About the Schedule? Aren't You Late?

Yes, we are a little behind schedule, thanks for noticing. As always, we face a trade-off between pushing stuff out aggressively and doing the right thing, in this case aligning the specs better and making sure Web Beans and Bean Validation fit well with the overall model. In my opinion, the choice is a no-brainer, given that developers have to live with a version of the platform for a long time. With the release of the public draft of the platform spec, every JSR scheduled for inclusion in Java EE 6 is now public, so we are getting close to the finishing line.

Please keep the feedback coming and let us know how we can improve your development experience!

With all the talk on profiles and modularity in Java EE 6, it's easy to forget that the main, ongoing focus of the last two EE releases is ease of development.

Until Java EE 5, the main concern was making the platform more powerful and comprehensive, so that enterprise developers would have everything they need to get their job done. For example, over time we added several technologies aimed at expanding the number of enterprise systems a Java EE application server can connect to: JMS, Connector API, JAXR, web services...

The release of Java EE 5 was a watershed event: the focus moved decisively towards making the platform easy to learn and use for developers at all skill levels. This led to the addition of several new, annotation-based APIs sharing a common set of patterns: Enterprise JavaBeans (EJB) 3.0, Java Persistence Architecture (JPA) 1.0 and Java API for XML-based Web Services (JAX-WS) 2.0. Besides placing more of the information in the source code itself, the use of annotations greatly reduced the need to edit XML-based deployment descriptors, one of the traditional scourges of Java enterprise developers.

In Java EE 6, we plan to continue the drive towards a simpler, friendlier platform. This time around, much of the focus is on the web tier, but there are important new features being delivered outside it.

Web tier

Servlet 3.0brings the annotation-based programming model popularized by EJB 3.0 to the web tier. Once again, the goal is to greatly reduce the need for editing the web.xml deployment descriptor.

But why are descriptors edited in the first place? It turns out that most web tier development is done using third-party frameworks and libraries, mostly licensed as open source. Each framework comes with a set of servlets, servlet filters and context listeners that need to be registered correctly for the framework to work.

In Servlet 3.0 we address this issue by introducing web.xml fragments which live inside library jars and contain a description of the infrastructure needed by the library to work. At application initialization time, the container will discover the fragment and process it as if it had been part of theweb.xml descriptor. The end result is pain- and error-free framework configuration for all applications.

Of course, the servlet expert group went beyond the basic use case and thoughtfully added an API to programmatically register new servlets at startup. I mention this fact here because it underlines a core principle of the new, annotation-based model, i.e. that declarative means should be complemented by programmatic ones to account for advanced use cases. The same principle can be seen e.g. in JAX-RS, with its separate packages for the declarative API (javax.ws.rs) and the programmatic one (javax.ws.rs.core).

By allowing developers to structure their application as a set of resources, JAX-RS makes it a lot simpler to implement RESTful web services. As some people are quick to point out, JAX-RS cannot and does not by itself guarantee that your application will adhere to all the REST principles, but it's certainly a lot more productive way to reach that goal than the alternative of rolling your own HTTP-aware application code.

JSF 2.0 too contains strong ease of development features, such as the support for facelets as a page declaration language. I'd also like to thank the JSF expert group for their determination in improving an often overlooked area, that of the error messages emitted at development time. In many ways, Java EE has historically focused on fully tested, ready-to-deploy applications, but the truth is that most of the hard work happens before that stage is reached. Any help that we can give developers in their quest to be more productive is certainly worth the effort (this is yet another instance of the "always remember who your customer is" principle).

Elsewhere

As I mentioned earlier, ease of development improvements are not limited to the web tier. A lot of the work going on in the EJB 3.1 expert group is directed at making EJB development even simpler. Among the many features, I'd like to single out three.

The new singleton bean type captures an often-desired pattern in an easy to use form -- as you may have guessed there is an annotation for it, @Singleton. With optional local business interfaces we finally achieve the goal of defining an EJB component in a single class file, with no interfaces and no deployment descriptors. Although the path may have been circuitous, the end result is something to behold. Finally, embeddable EJB will make testing your code a lot easier and help expand the reach of EJB technology to all Java SE applications.

Although space doesn't allow me to go over every new feature in the Java EE component JSRs (my apologies to all the expert groups involved), I'd like to mention a few more contributions to the ease of development cause that span multiple technologies.

The success of the EJB 3 programming model has renewed interest in using EJB components in web applications. In this respect, EJB 3.1 removes a significant barrier by allowing EJB component classes to be packaged directly inside a web application, obviating the need for multiple levels of packaging. Whereas previously you had to package a war file and an EJB jar file inside a larger ear file, now a single war file will suffice.

We are also looking at WebBeans to bridge the gap between JSF and EJB technologies, making it possible to use EJB components inside the rich, contextual web application environment. Gavin King's blog has more details on what WebBeans adds to the platform in this respect. Don't forget to read all the comments!

Finally, the Bean Validation JSR offers a uniform validation API (with annotations, of course) that can be used in conjunction with JSF, JPA, JAX-RS, Connectors, etc.

Conclusion

We think you'll be pleased with the ease of development features you'll find in the Java EE 6 platform. Granted, making something as powerful as Java EE easy to use is an ongoing, titanic struggle, but we believe that by continuously delivering improvements on this front release after release we are succeeding in keeping the platform fresh for existing users and in making it more approachable to those who discover it at this time. It's never too late to enjoy developing software.

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 yesterdayand 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 Braypointed 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 tenfive 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!

robc

Java EE 6 at JavaOne Blog

Posted by robc Apr 25, 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).

robc

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 TSSand InfoQarticles. 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.

Extensibility

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.

Modularity

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.

Update: See the related stories on The ServerSide and on InfoQ.

It's been several months since my last update on the work going on in the Java EE 6 Platform Expert Group (JSR-316).

The main topic of discussion in the EG has been profiles. There are several aspects to this, ranging from the number and contents of profiles to the somewhat more general subject of SPIs and pluggability.

By the far the most animated part has been the discussion around the Web Profile, with several definitions being proposed. Personally, I found it very interesting to see how EG members crafted their proposals by following different routes and aiming for somewhat different goals. This is a testament to the activity and liveliness of the platform.

At this stage, we think that the best path forward consists of polling the community for feedback on which definition of Web Profile they'd most like to see adopted by the expert group.

One reaction that people sometimes have is to ask: Why should we choose? So, as a premise, I should point out that profiles come at a cost. As the specification lead for JSR-316, Sun is responsible for delivering a Reference Implementation (RI) and a Technology Compatibility Kit (TCK) for each profile. Additionally, Sun needs to take all the legal and business steps to license the platform and each profile, provide support to licensees (including no-cost support for qualified ones), etc. This does not come for free.

In very practical terms, then, we cannot support a large number of profiles in the desired timeframe for the Java EE 6 platform. Here "large" really means "more than one".

Not all is lost though. One of the driving ideas around profiles is to move away from a big-bang model for the delivery of the platform, enabling smaller, focused communities to forge ahead in the context of a profile they define. It is natural then to achieve as much decoupling as possible from the beginning and push profiles into separate JSRs, to be finalized on their own timeline.

This said, we originally proposed defining a Web Profile as part of the Java EE 6 JSR because (1) it's helpful to have a use case at hand when developing the notion of profiles, as opposed to doing so in the vacuum, and (2) we believe that there is interest in the market and in the community for a web-centered profile of the EE platform. Incidentally, the amount and depth of EG mail that the Web Profile generated more than proved the first point.

To come to the central part of this post, here are the two profile proposals that got the most interest in the EG. I've tried to come up with a characterization of them in five words or less, but in the interest of not attaching strong labels or identifying the proponents, in what follows we'll simply call them A and B. As a reference, I also listed the contents of the full platform in the third column.

                       
(A)(B)Full platform
Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250
Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250
Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250
EJB 3.1 (Lite)
JTA 1.1
JPA 2.0
JSF 2.0 *
Web Beans 1.0 *
EJB 3.1
JTA 1.1
JPA 2.0
JSF 2.0
Web Beans 1.0
JAX-RS 1.0
Connectors 1.6
JAX-WS 2.2
JAXB 2.2
JSR-109 1.2
JSR-181 1.1
JMS 1.1
JAF 1.1
JavaMail 1.4
JSR-115
JSR-196
JSR-88 1.2
JSR-77 1.1
JAX-RPC1.1
JAXR 1.0


 

In (B), the inclusion of JSF 2.0 and WebBeans 1.0 is controversial, so we marked them with an asterisk (*). Not coincidentally, these are technologies which could be handled via extensibility (keep reading for more details).

Some clarifications are in order.

"EJB 3.1 (Lite)" refers to the idea of allowing implementations to deliver a subset of EJB 3.1. The contents of this "lite" subset are wholly undecided at this point, but as an example it might include the annotation-based programming model introduced in EJB 3.0, restricted to session beans with local interfaces (only). In other words, you could write an annotated session bean with a local interface and use it in your Web Profile-compliant product (assuming (B) is accepted, that is). But, for example, you could not write a EJB 2.1-style session bean, or an EJB 3.0 message-driven bean, or a EJB 3.0 stateful session bean with a remote interface.

It's important to note that proposal (B) assumes that "EJB 3.1 (Lite)" will exist, but this is a decision that is entirely up to the EJB 3.1 expert group (JSR-318), where it's going to be prioritized against other features. The precise definition of what comprises "EJB 3.1 (Lite)" is also left to the EJB 3.1 expert group, with no particular proposal being put forward as of today.

A second point worth discussing in some detail is related to extensibility, which you may remember is one of the goals of Java EE 6. As a feature, extensibility interacts with profiles, allowing some interesting scenarios to be played out.

First of all, in the web tier extensibility refers to the ability of taking advantage of third-party frameworks with a much simplified programming model. Developers won't need to manually edit the web.xml descriptor to add context listeners, filters, servlets and servlet mappings per the instructions given by their favorite web framework. Rather, adding a third-party jar to the web application will trigger the addition of all these elements, with no developer intervention. We expect that this feature will cover the requirements of all major web frameworks such as JSF, Struts and Spring MVC, scripting solutions like JRuby on Rails and Grails, WS-* web services following the JAX-WS 2.0/JSR-109 model and RESTful web services written to JAX-RS 1.0. One important point to note here is that extensibility is agnostic to whether a technology is based on a JCP standard or not.

Extensibility though is not limited to web technologies. Looking at existing JCP standards, it's going to be possible for a product that implements the Web Profile to also include additional technologies. The required precondition is that the technology in question must have a standalone TCK. This applies not only to technologies which are independently defined, but also to those who are required components of the full platform.

For example, assume that JAX-RS 1.0 (JSR-311) becomes part of Java EE 6. None of the two Web Profiles (A/B) includes it as a required component. Still, since JAX-RS 1.0 plans to offer a standalone TCK, Web Profile products may decide to offer support for it out-of-the-box. The difference with the case of a developer dropping a jar file for a JAX-RS implementation into the WEB-INF/lib directory is that the vendor of the Web Profile product would have certified the JAX-RS implementation and would presumably be supporting it.

Currently, not all technologies in Java EE 5 have a standalone TCK. For example, neither EJB 3.0 nor JTA 1.1 do. As part of the conversation in the EG around profiles, we at Sun have offered to make many more TCKs available in a form that is suitable for running them on a Web Profile product. These include TCKs for technologies like EJB 3.1 Lite, JTA 1.1 and Connectors 1.6. We believe that this will empower application vendors to ship Web Profile-compliant products that offer more than the minimally required technologies, to help bridge the gap with the full platform.

As an aside, I should point out that the recent trend toward more modularization in application servers will work very well with extensibility, by delivering a simpler, more effective way to manage the versioning and availability of libraries to applications.

As we expand the freedom to combine technologies in a product, the issue of compatibility requirements that span multiple technologies comes to the fore. For example, the Java EE 5 specification contains requirements that servlet containers must honor wrt the availability of JTA. The plan for Java EE 6 is to rewrite such requirements so that they will apply to any profiles and implementations thereof that contain the relevant combination of technologies. Going back to the example, any product conforming to any Java EE profile that includes both servlets and JTA will have to honor those requirements. The rationale has two components: on one hand, we think that the Java EE requirements add significant value to standalone technologies, as testified e.g. by the large number of servlet containers which implement JTA in a way that is compatible with what Java EE mandates; at the same time, calling out the requirements will help ensure that applications that target profiles will work on the full platform. Overall, this makes profiles more than just collections of independently tested technologies, because those technologies will be tied together in interesting ways, deliver more functionality than they would on their own.

This brings me to the last point I'd like to make. One concern we heard around profiles is that they might weaken compatibility. Essentially, if my application targets the Web Profile (however defined) + JAX-RS 1.0, then it won't run on any plain Web Profile product. Although that's technically true, it's important to recognize that there is an upward compatibility guarantee in the form of the full platform, at least when the added technologies are required components, as JAX-RS is. This is no worse than (and, in fact, better than) the current compatibility story for, say, servlets + Struts.

We do expect though that, whatever choice is made re the Web Profile, we may enter an "experimental" phase in which products with different feature sets will compete in the Web Profile space, until one feature set prevails. I'd describe that development as welcome and look forward to standardizing the winning feature set in a future Java EE profile. The Web Profile itself may evolve in the future by adding more technologies (but not by subtracting them, except via pruning), based on experience acquired after its first release.

It's also the case that the full Java EE 6 platform will always be there, offering an ample choice of certified Java EE 6 products from different vendors, to address needs that go well beyond what the Web Profile offers.

Filter Blog

By date: