Devoxx provides a great opportunity for the key Java EE players to meet and discuss topics of interest. With the recently released Java EE 7 platform this year’s Birds of Feather session goal was to collect feedback on Java EE 7, ideas and wishes for Java EE 8, and any thing else that would encourage wider participation from the community.

David Delabassee (Oracle), David Blevins (Tomitribe), Peter Pilgrim (independent), Johan Vos (Lodgon), several JUG leaders, and other interested community members were present in this meetup. And of course I was there too!

Here are my notes from the discussion:

• Feedback on Java EE 7: JCP 2.9 allowed different Java EE 7 JSRs to run transparently. Each project had a xxx-spec.java.net project (e.g. javaee-spec.java.net) and encouraged participation from the wider Java community. Interim spec drafts and API jar files were made available on the project Downloads area (e.g. javaee-spec downloads). Adopt-a-JSR allowed 20+ JUGs around the world to help shape up Java EE 7 platform.
• API and Specification source: The source files of the API classes and source of the specification needs to be checked into the workspace. This will enable interested members to play with the API classes and provide alternative proposals. A text-based format (e.g. AsciiDoc) for the specification source is strongly preferred. This will allow community members to provide concrete proposals for specific sections from the specification. This will also help the specification lead to easily merge the submitted proposals in the existing specification. A git-based repository is strongly preferred as it enables and encourages collaboration. For example, source code for CDI API classes is available here and the text-based specification here. If  git-based repository cannot be created then a mirror between the existing repository and git must be established.
• TCK should be open-sourced: A JSR consists of three components: Specification, Reference Implementation, and TCK. The specification is released under a fairly standard license. However as discussed above the source for API classes and specification needs to be made more publicly available. The Reference Implementations are released under an OSI-approved license. IBM led JSR 352 and the TCK is available under Apache License 2.0. Similarly Red Hat led JSR 346 and 349 and the TCK is available under Apache License 2.0. However TCKs for Oracle-led JSRs are available under this license (similar ones for other specifications). Open sourcing the TCK has been discussed multiple times in the past and Oracle already offers TCK to non-profits like Apache and Eclipse Foundation at no charge. However this still seems a last bit of “closed” piece in the otherwise fairly open and transparent process. TCK tests can also serve as extremely valuable resource for the developers to learn the technology. Adam Bien’s SmokeTests and Java EE 7 samples are turning out valuable resources for the developers and container implementors in lack of an open source TCK.A later discussion with David Blevins (founder of Tomitribe) revealed that it is very important to have TCK from the very beginning in order to implement the container and pass compliance eventually. Otherwise significant parts of the container need to be rewritten, as was done for Apache Geronimo, to get compliance. Open sourcing the TCK would certainly allow Tomitribe to work towards Java EE 7 compliance as well.
• Testing: 90% of the attendees were using Arquillian for testing their apps against single/multiple containers. There was no need felt to file a JSR and standardize it as that could possibly stunt the innovation in this area.
• Making contributions easier: Steps to contribute a patch to the Reference Implementation should be clearly listed. This is not restricted to but can typically include how to checkout and build workspace, high-level package overview, run smoke tests, steps to add new tests.
• Potential topics for Java EE 8: Simpler security, standalone CDI, Action-based framework, Event-driven system, standard way of achieving high availability on application server, ability to generate native mobile apps with a Java EE backend.

All in all, Hildeberto Mendonça summarized in three words “Because we care” on why the attendees showed up for the 7pm BoF. If you do care, get involved!

WildFly 8 is getting dressed and Candidate Release 1 is now anyday!