A long overdue post, I'm still excited to share that Seam in Action was translated (in 2010) into Korean and Simplified Chinese--two languages I can't even pretend to understand. It's pretty strange to see words that you spend countless hours revising look complete foreign to you. But exciting at the same time!

These books arrived in a box that clearly looked like it came out of a shipping container that was aboard an ocean carrier. My goal is that sometime soon (2012 perhaps?) I'll get to travel to where these texts originated :) (but hopefully on an airplane).

I have a whole stack of these books, so if you are in the DC area (or the US for that matter) and you want one of these books, just let me know. I'll mail it to you, free of charge.

Seizing the opportunity of a new Executive Committee (EC) under a new regime, I'd like to issue a call for reform of the Java Community Process (JCP) to allow it to produce more iterative and timely technology and live up to it's name as a "community process", rather than acting as the "corporate process" many believe it is today [1].

Goals and current problems

The goal and of this call to action parallels a statement made by Mark Little, CTO of JBoss and member of the EC, in response to questions for the 2010 EC candidates [2].

We believe that the EC still has an important role to play in the future of Java, and working within the EC is the best place to push for change and improvements. Java is certainly more "open" now than it was a decade ago, but it's not as open as [...] other standards bodies [OMG, OASIS, W3C and IETF]. We would like to see that change.

Indeed, the central problem with the current JCP is lack of transparency and openness. Although the JCP defines itself as "the open, participative process to develop and revise the Java technology specifications, reference implementations and test suites", it's not very open nor participative in practice. The community is almost entirely excluded when developing so called "open standards".

The root cause of this problem is that the Expert Group (EG) mailinglists are not open to the public (save a few exceptions, notably JSR-303 and JSR-311). The mailinglists are where the bulk of the technology design takes place. The private mailinglists don't merely close the doors to the general public. EG members from one JSR can't even read the correspondence of another JSR.

Feedback is one directional, from community to EG. All the general public can see are the drafts of the JSRs. They don't know how the EG arrived at that draft, meaning they aren't able to study the discussions that went into it. The EG may reciprocate by publishing another specification draft, with or without the feedback incorporated.

While companies and major Java leaders are involved in the JCP, individuals from the Java community have to really fight to be included or provide feedback. Let us not forget the significance of their participation, as Mark Little points out.

A strong JCP and a strong EC should be to the benefit of the entire Java community and not just to a select few.

The JCP also fails to respect the nature of software development. Instead of following an iterative process, JSRs target big-bang releases that have no clear continuum to the next generation. These major shifts in the platform make it increasingly harder for consumers to carry out migrations. Smaller releases would be easier to adopt. There are also huge lapses between releases, which is time for the technology to fall out of date.

How can we expect to define a unified and consistent platform that integrates well if the technologies bundled are created in different campuses at different times? The decisions that occur behind close doors effectively turn off would be participants and consumers. The community becomes frustrated because they don't know what's going on.

It's true that progress can emerge even from even a crippled process. There's no doubt that Java EE has been experiencing a revival since the release of Java EE 6, but with no clear target for EE 7, how long can the honeymoon last? Bill Burke cites how a small company like Red Hat has been able to make a big impact on the JCP standards [3]. He provides this evidence to make the point that the JCP is salvageable. Great, so let's salvage it and get it moving again.

The call for reform

I propose that the JCP redefine itself as:

To make it very clear what changes I'm calling for, I've itemized them below, ranging from "must have" to "nice to have".

Must haves:

• Specifications must be published under and open, non-clickthrough license, which covers the specification documents, the APIs, the reference implementations and the compatibility test suites
• Specifications should be free to use and implement (no TCK fees)
• Specifications must provide a non-clickthrough specification document, stored in an open VCS system and easily viewable online by anyone (a nightly build of the spec would be sufficient of the document is created by for-pay software)
• Specifications should be required to publish API binaries, sources, and JavaDocs to Maven Central
• Specifications must have public issue trackers, open source TCKs and public mailinglists for all JSRs, and require information about these resources to be public and easy to find
• Expert Groups (EGs) should not be automatically disbanded after a final release of a spec (maintenance releases are an extremely important part of a JSR's evolution)
• Maintenance releases should be easier to initiate (and get approved); the software process should be iterative
• Names of individual representatives, and the company they represent, should be listed on the specification page; it should be clear who the representatives are
• There should be an official process for deprecating or removing a technology; old technologies currently die a slow unused death, dragging the platform down, and leaving complexity in its wake as vendors are required to pass the TCKs; let's not hide behind the term "pruning"
• All specification communication must be considered public, and should be archived, unless initiated privately by a member of the community

For accessibility:

• Specification documents should be made available in HTML format for easy web access; PDFs should merely be one viewing option, not the only one
• Specifications should provide end-user, user-case driven documentation for a technology (for instance like the first half of the Weld reference guide and the Java EE tutorial)
• Decent and familiar social business software should be used for jcp.org to make it truly a community (jcp.org is extremely difficult to use and poorly organized)
• jcp.org should host all the specification artifacts (specification document, API, reference implementation and TCK) (there is currently too much burden on developer to find them)
• Specification artifacts should require no more than two clicks to begin said download, with no login required

Nice to have:

• Periodic EC meetings should be open to the public
• Platform releases (i.e., Java EE) should occur at regular, scheduled intervals, every 6 months or so, with clear paths for ratification and deprecation of JSRs.
• The JCP should be an independent organization, similar in structure to the Eclipse foundation; it should be run and funded by donations/investments rather than petty membership fees
• JSRs must be allowed to compete with each other, or standards evolution merely excludes and fragments participation within the Java community (for instance, one view technology is not sufficient)

Support and endorsement

The evidence of a general call for JCP reform is widespread.

Earlier this year, Mark Little, Red Hat's representative on the EC, called for a more open process, with everyone acting as peers. [4] He reinforced those statements in his follow-up to questions posed to the EC candidates. [2] IBM states on their standards page that they will "begin or end participation in standards bodies based on the quality and openness of their processes, membership rules, and intellectual property policies." [5] Bob Sutor has said that IBM expects to see "long needed reforms in the JCP [...] to make it more democratic, transparent, and open." [6] In an open letter from the CTO of SAP, Vishal Sikka, he calls for more openness in the JCP, saying "To ensure the continued role of Java in driving economic growth, we believe it is essential to transition the stewardship of the language and platform into an authentically open body that is not dominated by an individual corporation." [7] Darryl K. Taft published an editorial in eWeek outlining 15 guidelines for making Java better, one of which included setting the JCP free. [8] Doug Lea made a firm statement a few weeks ago that the JCP is no longer a credible standards organization [9]. And we cannot forget the long-standing open letter from the Apache Software Foundation to Sun asking to have the IP rights restrictions on the Java SE TCK removed. "[F]ailure to comply with your contractual obligations poses serious risk to the credibility of the JCP as an open standards organization, and the reputation of Java itself as an open technology." [10]

There are numerous other public statements on the web of calls for JCP reform.

Summary

I'm calling for reform of the JCP. I want the JCP to be accountable to its namesake, a "community process." The fact that the JCP claims to be open but does not uphold this promise tarnishes it and causes people to lose trust. It's a tragedy that the technology is way ahead of the process.

But hope is not lost. A few fundamental changes would drastically improve the effectiveness and credibility of the JCP. As Mark Little has said, "we would like to see the JCP continue to evolve and address those issues which we all know tarnish it."

I hope that the new EC is brave enough to rise to this challenge.

Signed,

Dan Allen
Lincoln Baxter, III (see companion post)
This call to action represents my personal viewpoints. I am not speaking on behalf of my employer.

Add your signature to the corresponding entry on PetitionOnline to show your support. (The petition is merely provided to centralize the list of those in support of this call).

References

1. http://www.javalobby.org/java/forums/t103921.html
   http://ocpsoft.com/java/why-doesnt-jpa-jma-jta-ejb-jsf-cdi-work-jee-is-too-complicated
2. http://wiki.jcp.org/boards/index.php?t=5396
3. http://bill.burkecentral.com/2010/10/26/jcp-is-salvagable
4. http://www.computerworld.com/s/article/9171838/What_users_want_from_Oracle_s_Java_Community_Process?taxonomyId=63
5. http://www.research.ibm.com/files/standards_wikis.shtml
6. http://www.sutor.com/c/2010/10/ibm-joins-the-openjdk-community
7. http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/16648
8. http://www.eweek.com/c/a/Application-Development/15-Ways-Oracle-Can-Make-Java-Better-and-Improve-Its-Stance-with-Developers-271933/
9. http://gee.cs.oswego.edu/dl/html/jcp22oct10.html
10. http://www.apache.org/jcp/sunopenletter.html

I always wondered how Mojarra (the JSF Reference Implementation) managed to initialize without requiring a Servlet lifecycle listener entry (using the <listener> element) in web.xml. I figured it was either initializing on the first request or otherwise relying on some container integration. People would have likely complained already if the first approach was used, and the second doesn't make sense because Mojarra boots even in a Servlet container.

I finally discovered the secret while trying to get JSFUnit to work in Jetty from an Arquillian test. Mojarra wasn't loading. I switched to MyFaces and it also failed to start. But this time, I got an interesting error message along with it:

java.lang.IllegalStateException: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions!

If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml.

Aha! That's the ticket. The JSF implementations are using a TLD file in the JSF implementation to register the listener so that it doesn't need to be setup in web.xml!

That prompted me to take a look at the JavaDoc for MyFaces' StartupServletContextListener. There, the full strategy is laid out.

This context listener is registered by the JSP TLD file for the standard JSF "f" components. Normally, servlet containers will automatically load and process .tld files at startup time, and therefore register and run this class automatically.

Some very old servlet containers do not do this correctly, so in those cases this listener may be registered manually in web.xml. Registering it twice (ie in both .tld and web.xml) will result in a harmless warning message being generated. Very old versions of MyFaces Core do not register the listener in the .tld file, so those also need a manual entry in web.xml. However all versions since at least 1.1.2 have this entry in the tld.

That prompted me dig into the documentation for the listener element in TLD files. I learned that this capability was first introduced in JSP 2.0, part of Java EE 5. The Java EE 5 tutorial explains the function of the listener element as follows:

A tag library can specify some classes that are event listeners. The listeners are listed in the TLD as listener elements, and the web container will instantiate the listener classes and register them in a way analogous to that of listeners defined at the WAR level. Unlike WAR-level listeners, the order in which the tag library listeners are registered is undefined. The only subelement of the listener element is the listener-class element, which must contain the fully qualified name of the listener class.

The reason JSF wasn't loading in my Arquillian JSFUnit test was because I inadvertently left out the TLD processor (TaglibConfiguration) from the Jetty context in the Arquillian container adapter. I guess I now have motivation to add it back in ;)

So now you know.

During my long flight to Frankfurt last month, I responded to an interview by Jan Groth about Seam for the German Java Magazin. In the interview, I reflect on the value of Open Source, how I got involved in Seam and where we are headed with Weld and Seam 3. I ended up writing so much (surprise, surprise) it had to be split into two parts. I justify my thoroughness in my first response:

I'm going to be a little long-winded [...], but I think it's important to communicate what led me to Seam because it says a lot about the software itself.

The full, 2-part interview is available online at the JAXenter Magazine website:

• Part 1: I Didn't Want Others to Overlook this Framework
• Part 2: CDI and Seam 3 are the Future of Both the Seam Community and Red Hat

In part 1, I share the thoughts I had after reading the Seam reference documentation the first time:

It's like the Seam developers were reading my mind. [...] I felt like a kid in a candy store. I started banging out applications in no time and I was happy with how they looked.

I go on to explain that it wasn't just enough for me to know about it. I wanted other to benefit too.

I didn't want others to overlook this framework given how much it helped me. While the manual made sense, I knew it wasn't enough. [...] I decided to yell from the mountaintops by writing a series about it for IBM developerWorks.

The overwhelming feedback from that series made it pretty clear, someone needed to write a book about it (a higher mountaintop) that was going to explain every last detail. I took on that challenge (and believe me, it was quite a challenge.) [...]

I quite literally immersed myself in Hibernate, JPA, EJB 3, JTA, JSF and Java EE 5 in general. I came to appreciate the value of the platform, the remaining limitations and what Seam had to do to fill in the gaps.

I squeeze in a short review of the Art of Community at the end of the first part because it really sums up my vision of this project:

The Art of Community is a truly inspiring book and it reminded me why I love doing what I do...it's really about the people and the ideas. We are not just writing software for the community and publishing it as Open Source. It's the community's software, solutions to problems that come from the real world. We want to support and foster that engine and the Seam Community Liaison is the spark plug of the engine and ensures it's properly greased.

Part 2 dives more into the technical details and where we are headed.

CDI and Seam 3 are the Future of Both the Seam Community and Red Hat.

I explain our standards strategy as a defender of choice:

Red Hat is strong when the Java EE platform is strong. Our strategy does not depend on the platform remaining weak to justify the existence of our projects. It's quite the opposite. If we make one of our own projects obsolete, or some part of it, that's progress.

To quote Jay Balunas, it's cyclic:

Find a void. Fill the void. Standardize the fill.

I liken Seam modules to JSF UI component libraries and explain how we will ensure portability:

1. Seam 3 is primarily built on the CDI portable extension SPI, insulated from handling low-level concerns that run a high risk of breaking portability.
2. One of the principal requirements of Seam 3 modules is portability.
3. The Arquillian in-container test framework allows modules to be continuously tested against an array of application servers.

But with the improvements to Java EE, the question comes up whether Seam is still needed:

Is Java EE 6 a solid platform? Yes. Will you still need extensions? Yes. And CDI was designed specifically to be able to root and foster such an ecosystem. You can even write your own extensions, which really wasn't possible with Seam 2. Now we just need a plug-in site ;)

I'm very excited about all the innovation that is taking place in the JBoss Community right now and I encourage you to become a part of it. You never know where it will lead, but I can guarantee you it will open doors for you.

This post is syndicated from my JBoss Community blog.

Despite all that I have written, explained and presented about Seam, I often find myself struggling to sum it up in a few short breaths. Fortunately, Matt Campbell does an superb job of defining the essence of what Seam provides eloquently and concisely in his blog series An Honest Look at Seam. (And I'm not just saying that because he credits Seam in Action as being his guide in his exploration of Seam).

• An Honest Look at Seam - Part 1: How Seam builds on Spring
• An Honest Look at Seam - Part 2: The Conversation
• An Honest Look at Seam - Part 3: Learning Seam

In part 1, Matt explains how the attention to scoping of components is what sets Seam apart from Spring and makes it more suited for the web environment. In my talks on Java EE 6, I often say that JSR-299 (CDI) considers the scope of a bean (where it's stored) to be just as important as the component instance itself. Speaking of Java EE 6, Matt does some comparisons of his own between Seam and CDI.

Having established the importance of context, Matt opens part 2 introducing the conversation scope. He quickly delves into the symbiotic relationship between this scope, the persistence context and the multi-request use case (which is just about any use case on the web). He raises the ever important issue of manual flush mode in Hibernate and how it enables use of an optimistic transaction.

Matt takes a break from the theory in part 3 to address the developer's first experience with Seam. He calms the anxiety a typical newcomer might have the first time the developer observes seam-gen churn out application. While some may appreciate the huge boast that a fully-functional application provides, the shear number of artifacts is daunting for those expecting "Hello World". But as Matt clarifies,

There is a lot to Seam, but not becuase Seam itself is vastly huge and complex, but because Seam integrates so many things together.

So take your time and explore it all. Use what parts you need and skip the parts you don't.

In the future, rather than struggling to find the words to describe Seam on a trip in an elevator, I'm just going to hand the interested listener a card with the URL to these blogs on it ;)

It's important to zero in on what Seam 2 provides, especially as we look ahead to Java EE 6 and the development of the Seam 3 portable extension library. So regardless of where you are in your adoption of Seam 2 or Java EE 6, take a moment to read through these entries.