Tag Archives: devoxxuk

Java EE BoF at DevoxxUK Notes

conferences, javaee

2014-06-12 19.45.54

The usual Java EE BoF at DevoxxUK was another chance for community members to meet and discuss the past, present, and future of Java EE. The gathering happened on the first anniversary of Java EE 7 and so allowed us to focus on what happened in the past year and start focusing on what’s expected from Java EE 8.

Here are some notes:

  • Meetup started with the usual pet peeve of no official Java EE logo. @Java_EE is the “official” twitter handle which tweets about technology, compliant application servers, and competitive analysis that favor Oracle 😉 This handle has an image but there were personal opinions about its usage, with no clear consensus or statement from JCP or Oracle, on whether this is the official logo of Java EE as well.
  • Another constant running pet peeve is how the information around Java EE is scattered in different websites. There is official Java EE 7 tutorial by Oracle and 200+ samples/tests (with 33 contributors from the community), and Adam Bien’s samples. These are good for somebody who has a basic understanding of the technology already. But there is nothing for a newbie to Java EE. No single website that shows Java EE design patterns, how the technology has evolved over the years, comparison with Spring, why choose one over another, different application servers and their compliance level, relevance of production support in an open source world, tool set, and the list goes on. Antonio Goncalves (@agoncal) raised the point that if somebody registers javaee.io, then would Oracle send their lawyers after the person who registered the domain ? David Delabassee (@delabassee) mentioned that there might be some announcement to that effect at JavaOne, so wait and watch.
  • Antonio talked about how Java EE platform consists of a profile, and a profile can consists of multiple specs. He proposed a further granularity where a spec could be divided into multiple parts, such as CDI could be divided into core, injection, interceptors, etc. Different specs (existing or new) can then define what pieces of the spec they depend upon. This does rely upon modular platform. As we know, modularity is not coming to Java SE in the near future. So if this needs to be achieved then Java EE platform will have to define some mechanism of its own. David Blevins (@dblevins) particularly brought a good point that just because CDI is a good specification, that should not mean that everything should be added to CDI and make it a bloatware. We need to protect JSRs that are good and keep them light.
  • Nigel Deakin announced that JMS 2.x is getting planned. Some of the key focus there is to simplify Message Driven Beans, leverage connectors (this is David Blevins’s favorite topic ;), and allow messaging dispatching using JAX-RS-fashioned APIs. It was highly recommended that no new bean type should be introduced. Nigel is looking for supporters of the JSR.
  • David also mentioned that JAX-RS.next and Servlet.next are getting planned as part of Java EE 8. There is a already a flurry of activity on MVC support in JAX-RS. Similarly should support for Server-Sent Events be included in JAX-RS, or outside it ? There was as a suggestion that JAX-RS should expose an SPI and other specs should be able to leverage that SPI to add features to JAX-RS, instead of making it part of the core spec itself.
  • Anatole (@atsticks) talked briefly about the Configuration JSR which should likely be filed before Java EE 8 as well.
  • There was interest on having an embedded Java EE server. The user should be able to deploy the WAR file and the runtime should be able to detect dependencies and load the right set of containers.
  • There was still no urgency to provide a standards-based PaaS platform. However even though JSR 88 is formally deprecated but there were discussions about bringing a Devops-style API. This was also discussed during JavaOne 2013 as well.
  • Another constant pet peeves is the different styles of Logging API. There is no standard API in Java EE to log and each application server picks their favorite framework. This makes the job of application developer challenging.
  • JMX 2 might be revised as part of Java EE 8. There was a brief discussion on exposing JMX beans as REST endpoints.
  • There was also discussion around that there should be a separate Java Community Process track at JavaOne. This would provide beginner to advanced sessions on JCP, and hopefully encourage more members to join JCP and contribute.

Please leave a comment on the blog for any updates.