Airhacks BoF, Nashorns and Macroservices at JavaONE 2015
BOF1849 (BOF (Birds-of-a-Feather) Session), Most Popular Java (EE) Q & A--Airhacks.tv Live
During this BOF, I’m going to answer most asked questions about Java, Java EE and Enterprise live from JavaOne. Questions from the audience will have preference. After answering all live questions, I’m going to discuss questions from IRC (#airhacks), twitter and some FAQs. Free beer might be included. See: http://airhacks.tv
[I will try to live stream this session as usual. In worst case I will publish the session afterwards. Does anyone know how to order beer for the audience at JavaONE? Help is highly appreciated]
CON1850 (Conference Session) Nashorn--The "42" For Start-Ups And Enterprise
Nashorn enhances Java 8 with scripting capabilities out-of-the-box. In “standalone” mode Nashorn can be used as debuggable and unit-testable shell scripting / batch replacement. In this session I will present use cases, ideas and solutions for Nashorn usage in server side projects in continuous hacking style. From validation, anti-corruption layers, fluid logic, grids and agents to template engines. Questions during the session are highly appreciated.
CON1851 (Conference Session), From Macro to Micro (Services) and Back--On Stage Hacking With Java EE 7
Pragmatic Java EE 7 applications are lean, fast and come with short turn-around cycles. Java EE 7 on Java 8 becomes the natural choice for micro service architectures not only in the enterprise, but also increasingly for start-ups. In this session I’m going to build, discuss and deploy (on docker of course) a micro service application and discuss the challenges, communication styles and “best practices”. We might end with a Macroservice architecture and so the next hype. Questions are highly appreciated and are going to be immediately answered.
See you at Java EE Workshops at Munich Airport, Terminal 2 or Virtual Dedicated Workshops / consulting
Happy second birthday, Java EE 7! How is it going in production?
In our quest for Java EE integration, we’re trying to actively embrace the latest generation of specifications such as JPA, Bean Validation and of course the Servlet and JMS APIs. As of Spring 4, we’re supporting the Java EE 6 and 7 level of specifications side by side. We would like to raise it to the EE 7+ level (e.g. JPA 2.1, Bean Validation 1.1, and in particular Servlet 3.1 and JMS 2.0) soon but are facing a fundamental problem: the lack of EE 7 platform adoption.
The Java EE 7 platform has been released in May 2013 and is therefore two years old now. Surprisingly, it’s hardly to be found in production yet. But then that’s not so surprising really: While a few projects have been certified for EE 7 in the meantime, the lack of major vendors is apparent: There are no major EE 7 servers with production support yet, not for the web profile and not for the full platform either. As of June 2015, the common EE vendors still sell licenses for servers based on 2009-era Java EE 6 APIs. And it’s not just the traditional suspects:
Tomitribe provides support for TomEE 1.7, a Tomcat 7 based EE 6 Web Profile stack, based on 2009-era EE 6 APIs but compatible with JSR-356 WebSockets and JDK 8 at least. TomEE 2.0 will be an EE 7 offering based on Tomcat 8 but hasn’t been released yet.
Red Hat’s most recent support offering is JBoss EAP 6.4, a JBoss 7 based EE 6 stack with JSR-356 WebSockets and JDK 8 support in the meantime. Note that WildFly is an R&D project without maintenance releases and without any kind of production support.
Oracle ships WebLogic 12.1.3, an EE 6 server with a bit of EE 7 (JPA 2.1, JAX-RS 2.0, JSR-356 WebSockets) and JDK 8 support. WebLogic 12.1.4 as a full EE 7 server has been announced for a long time now but is still not released. And GlassFish 4 is just an RI…
The IBM WebSphere team does a fine job implementing EE 7 specs for the WebSphere Liberty Profile but hasn’t completed the effort yet. At least, some EE 7 modules and JDK 8 are supported in production already, as a kind of feature pack for the Liberty Profile.
While several specifications from the EE 7 umbrella have seen individual adoption, e.g. JPA 2.1 through Hibernate 4.3 and Servlet 3.1 / JSR-356 WebSockets through Tomcat 8 and Jetty 9, it is fair to say that Java EE 7 failed to enter the market as a platform overall. Ironically, the later-released JDK 8 got embraced in production rather quickly, even in EE land! So the state of the art as of mid 2015 is a vendor-supported Java EE 6 server running on JDK 8 in production…
Our consequence: Given the adoption levels of Spring 4 and Java 8, we’ll raise the minimum to JDK 8+ in our Spring Framework 5 generation. However, due to the lack of Java EE 7 platform adoption, we’ll have to retain compatibility with the current generation of application servers: allowing for upcoming Spring 5 applications to be deployed to the JDK 8 based EE 6 servers commonly found in production - just like we do with Spring 4 already, but at least with the extra benefit of going JDK 8+ for our framework codebase and all of its core interfaces.
Posted by JUERGEN HOELLER on June 05, 2015 at 08:34 PM CEST #