[null, {"document_url": "http://www.xenonique.co.uk/blog/2017/10/13/javaone-2017-in-depth-java-ee-eclipse-foundation-and-native-serverless-cloud/", "unformatted_src": "http://www.xenonique.co.uk/blog/wp-content/themes/xenonique-wp-design/assets/img/DSCF2329_cropped_256w.jpg", "src": "http://www.xenonique.co.uk/blog/wp-content/themes/xenonique-wp-design/assets/img/DSCF2329_cropped_256w.jpg", "formatted_filename": "DSCF cropped w"}, null, {"document_url": "http://www.xenonique.co.uk/blog/2017/10/13/javaone-2017-in-depth-java-ee-eclipse-foundation-and-native-serverless-cloud/", "unformatted_src": "https://farm5.staticflickr.com/4457/37518199312_5fdafeb43d_c.jpg", "src": "https://farm5.staticflickr.com/4457/37518199312_5fdafeb43d_c.jpg", "formatted_filename": "fdafeb d c", "alt_text": "IMG_6915"}, null, {"document_url": "http://www.xenonique.co.uk/blog/2017/10/13/javaone-2017-in-depth-java-ee-eclipse-foundation-and-native-serverless-cloud/", "unformatted_src": "http://www.xenonique.co.uk/blog/wp-content/themes/xenonique-wp-design/assets/img/DSCF3801_1024w_just_cropped.jpg", "src": "http://www.xenonique.co.uk/blog/wp-content/themes/xenonique-wp-design/assets/img/DSCF3801_1024w_just_cropped.jpg", "formatted_filename": "DSCF w just cropped"}, null]

JavaOne 2017 in Depth – Java EE, Eclipse Foundation and Native Serverless Cloud

13 October 2017 Comments off


13 minutes



I left the second article with the feeling of a less ostentatious technology conference about JavaOne 2017. On the other hand, the conference was packed with information on where Java the language, the runtime and platform with community are going to.
In this third article, I want to dig into the future of Java EE and where it is heading to.

Enterprise edition

The Enterprise Edition is an extension of the standalone Java SDK as Sun Microsystems imagined it way back in 1998. It was designed as a framework, library and runnable container for Beans that lived on the server side. The history of J2EE is mangled, long and varied and I will not care to extrapolate it here in this article. Suffice to say, that Oracle announced the transfer of the brand Java EE #1 to the Eclipse Foundation. Executive Director, Mike Milinkovich, announced the Eclipse Enterprise for Java, EE4J – Top Level Project with charter. #2

The Java EE brand
The Java EE brand is unfortunate failed marketing scheme, because technologists have long memories about the original Enterprise Java Beans in the early J2EE releases 1.0 to 1.4. EJBs were too hard to work with, develop and deploy solutions. Application server were proprietary and expensive, which left a glaring business opportunity with market. This was taken by Rod Johnson and his Spring Framework, which was open source and explicitly targeting Plain Old Java Object (POJOs). Finally, the name J2EE has stuck around in recruitment consultants mind, business managers and enterprise architects, despite Sun Microsystems and Oracle renaming the standard to Java EE. In my opinion, this is an example of #Fail!.
It would appear that Eclipse Foundation are at the time of writing failing or ignore the branding name issue. When J2EE was rebranded to Java EE, it didn’t work. The exercise never triggered renew interest in Java enterprise programming. Go and see any Java development job board anywhere in the world, I bet you find and read a description asking for J2EE development experience, for a technology that was ended by 2007 (Java EE 5). JavaOne 2017 will be remembered for the surge of interest in Java 9 modules and migration

Just what are these funny medicine pill buttons #0? (Click on me)
These are popover dialogs that go with the article and provide additional information to the audience
in my writing. Finger or press your mouse button off the dialog to dismiss these handy notes!

“Moving Java EE to the Eclipse Foundation is going to be an exciting and massive undertaking. It is a significant opportunity to use the Eclipse open development model to accelerate innovation in Java for enterprise and cloud native computing.”

Accelerating Microprofile

At JavaOne, I attended the session Panel: Accelerating the Adoption of Java EE 8 with MicroProfile panel session with David Blevins (Tomitribe), John Clingan (Red Hat), Mike Croft (Payara), Mark Little (Red Hat) and Kevin Sutter (IBM). I also witnessed David Delabassée and Linda DeMichel attending the same session sitting along the back. I could imagine that the two Oracle folk felt a little strange in the circumstance passing on the responsibility of Java EE to the Eclipse Foundation representatives on the panel. The mood of the session was generally in a warm spirit and the panel were approachable. When asked about the future of enterprise edition profiles, David Blevins, said that he hoped that Web Profile would continue, especially because Tom EE is based on it. Tomitribe had to jump through hoops in order to release a 2016 edition of their solution. “Tomitribe took a long time to write a Java EE 7 container, because we didn’t want to endure the expense of the TCK [Technology Compatibility Kit]. Apache Tom EE is based on the Web Profile, so it is paramount that it survives. There were lots of bugs, issues and differences in how application server tests were done in our Java EE 7 port. It was very hard without access to the proper framework. Moving to Eclipse should ensure that we solve that problem forever.”

John Clingan also offered, “In the future, there might be more profile, but at this point we just don’t know and it is way too early to decide. Going forward the Full Profile and Web Profile will be supported.”

Mark Little said, “The Microprofile is intended for innovation. A standard process is not the best place for innovation. Libraries that get proven within the Microprofile ought to be considered for a future EE standard.” From my own perspective, I liked the fact that representative panel were open to new ideas and had plans to reach out to developers, designers and architects. The panel encouraged the community to get involved with EE4J as quickly as possible.

MVC 1.0 to Eclipse Foundation

Java EE 8 was supposed to provide a lean Model View Controller (MVC) specification for action based web frameworks under the
JSR-371. However, because the umbrella specification was seriously delayed [because of Oracle’s Cloud Native internal work and resources] the MVC specification 1.0 was removed from the Java EE 8 specification in September 2016. Oracle agreed to transfer MVC JSR intellectual property to Ivar Grimstad. Just after JavaOne 2017, the late breaking news is that MVC is now transfered to the EE4J and the Eclipse Foundation. There is an accompanying email message to confirm this story.

During the conference, Mark Cavage was at pains to outline the reason to transfer Java EE to the Eclipse Foundation. Oracle wanted a faster progressive release, but it wanted to turn over the responsibility to the Java EE licensees and the community. Cavage appealed to the wider Java community to embrace the transfer of #JavaEE during the keynot. However at the during the same keynote, Spotify‘s’ Cloud Director, Niklas Gustavsson revealed that his company went from being a PHP shop to agile developer-operation Java development engineering teams with 1200 microservice in production. At an earlier conference keynote with Intel’s Michael Greene introduced Kingsum Chow, chief scientist Alibaba, who told the world that I they employ 10,000 Java programmers. Alibabi execute 1,000,000 JVM instances in their distributed production environment. The company serves 12.5 Billion hits on Single Day far ahead of the USA’s Thanksgiving.

Analysis: Microprofile versus Spring Boot

Whilst transferring the responsibility of Java EE is to be applauded, I couldn’t help to feel that the platform is left far behind where it should have been. The current Java EE 8 solution could not support Spotify’s infrastructure. It is difficult to see how any modern Java EE application server (in full profile) can reach this deployment of 1200 JVM instances. Consequently, Oracle turned its attention to the target that it thinks lies behind Microservices/SOA. The idea of so-called Serverless computing is appealing to many. Instead explicit marshalling of data between sets of APIs, REST or SOAP or otherwise, launching functions across a network boundary, which appear to be seamless and orchestrated on a dynamic distributed thread pool executor matrix could be the answer. Despite, whatever warnings from history, every sort of easy abstraction ultimately adds a level of accidental complexity to application and it is that leakage of the abstraction that can never be quite suppressed to zero, which causes inflexibility, bit-rot and technical debt, Oracle have invested heavy into FN Project, Wercker and Apiary.IO. Java EE traditionally based on Web Archive, Enterprise Archive Zip file and deployment into remote pooled bean containers and servlet containers inside a monolithic architecture might have had it’s day.

Modern organisations want a flexible and sustainable architecture without the cruft of a monolithic container that blocks the scalability and high availability of user / customer demand. It is for this reason, Microprofile, was defined to appear to streamline the multitude of JSRs, library and components for a Java EE enterprise application. My own fear is that the Microprofile falls way behind the surge in interest Pivotal’s Spring Boot Project. At best, this delay is one year and at its worst, it could be three years, at which point the competition would be game over. As I write these musing in early October 2017, let me just say, the current job descriptions for contract and permanent engineers who know Spring Boot, Java 8, Agile and microservices architecture, in London and Home Counties, UK have exploded.

The question is why has this occurred? What is behind the popularity of Spring Boot as a soluition?

Perhaps the most significant development with Spring Boot applications is that Pivotal offers its own cloud hosting under Cloud Foundry Microprofile 1.2 #7. Spring Boot fits in very well with the [SEC-]DEV-OPS mindset of Docker containers, composability and elastic deployments. Microprofile does not offer any native cloud support [yet]. Developers have to build their own supporting deployment infrastructure with Microprofile. At the time of writing, Microprofile 1.2 #3 only has these functionality from the Java EE 7 / Java EE 8 specifications, namely: JAX-RS, Bean Validation, CDI, Config, Fault Tolerance and Health Metrics.

The Microprofile was launched in September 2016 as a reaction to Oracle’s lack of commit and push for Java EE 8.
Cloud Foundry
Cloud Foundry was originally a pet project started by fellow Java Champion, Chris Richardson. He later sold it to then Spring Source in 2008, and in 2009 VMWare Inc acquired Spring Source. Alas, Chris Richardson may have missed out on Squillions of US Dollars!


Let’s step back a bit and consider the ramifications for Microprofile, what would it need to have to successful in, say, 12 to 18 months time in the future. Consider the hardware specification of trusty Apple iMac computer. Suppose we went into an Apple store to buy ten of these popular development machines for a new software engineering team, and suppose want to allocate them to pair-development programming and we are going to building microservices for the new project. We don’t care about the vertical sector: industry could be retail, financial, shipping, government or just digital e-commerce. I would recommend spending all of the money that you can to get the best specification available. In the UK, this would be the top range model

Why? Because of what we are going to do as a team, we will be writing 25 separate micro-services, at best guess, and that means every development-pair would be launching at 25 Java Virtual Machines simultaneously during their working day. The reason is END-TO-END TESTING #4. All considered, that our new team, are building against the final JDK 8 update 144 release just before Java 9 went GA, and have yet to migrate to Java 9 and Modules.

Yes. I do know there are some very advanced digital and highly Agile team out there already working with microservices and when they commit code it deploys directly to a cloud environment. I also know that sophisticated can also remote debug applications in a cloud sector, but bare with me for this article*, most SME are not definitely not Netflix, Facebook, etc.

Microservices Performance

As an engineer I have witnessed the high resource demands for newly minted micro-services applications #6. Consider that a modern editor like NetBeans, Eclipse and IDEA will chew up memory and CPU for their own demands. Most of developers at some stage in their project, have had to fine-tune the memory of IDE on their workstation by adding a JVM parameter into increase the maximum memory -Xmx1535m beyond the default value. Also projects tend be across scores of firm-wide code repositories, it is not uncommon to find yourself with six window frames of code during the day. During the day, spinning up 25 Java 8 JVM instances on a single iMac (or PC) takes its toll. Executing all of the JVM instances with -Xmx1024 requirements is going take serious grunt. The hope is with Java 9, in a well-thought out modularised microservices application, this demand on memory and CPU is less. Well for instance, why do we need corba.jar, awt.jar and swing.jar in a server-side application (actually these JARs did not officially exist pre-Java 9 JDKs, because the traditional JVMs (pre-version 9 jigsaw) all shared a library rt.jar. Modularity means this runtime rt.jar and replaced by a potential small Java Runtime Environment for each microservices.

This sidebar is an addendum to the first version of the article. Some engineers wanted information about the memory and performance issues of running JVM instances on a single laptop or desktop.

Are you starting to get the picture of why we need so much on their grunt on these development machines? In the traditionally Java EE world of full profile application servers, would you envision launching 25 WildFly 10 servers or 25 WebLogic servers simultaneously from a Bash script? The machine would grind to halt, if we could only beg the management for Dell Windows Vista desktop PC from the year 2007. Hence new microservices development incurs are high hardware, software and a human resourcing cost for most businesses. However, if you launched 25 Tom EE, Plain Tomcat, Jetty or may be Payara Micro instance, you might get away with it, but still. When we are in environment where we launch 25 microservices on a single machine, not inside a Docker container, we also are going to running an IDE be it Eclipse or, better yet, IDEA Ultimate. Our programming language editor of choice had better be lean and mean with our limited CPU resources, especially if we choose to launch a few of those JVM instance in Run/Debug configuration mode, and especially when we are investigating a crucial issue in our code-bases (note the plural in that last word).

So when we run our E2E testing, we must ensure the Identity Instance Runtime Profile is viable. In other words, by running tests where there at least one instance of our microservice in our distributed application, we have a baseline and confidence that will scale in production #5.

Testing M/SOA
Of course this is not the whole story, but run with it for now. In fact, checking viability of microservices is a complexity job and there are lots of considerations of how best to get the right heuristics.

Are the pennies dropping yet?

If you have been following my blog, you will know probably that I claimed JDK 9 is a game changer for about two years now. Consider that JDK 9 and modules allows you strip down your Java Runtime to only the modules that you need in your application. Are the pennies dropping yet? Suppose I told the engineering team today, that JDK 9 is released, let move to Java 9 and upgrade from Java 8. What do you think that will do with the 25 JVM instances that we run in our E2E tests? Suddenly, it will be far easier to launch the 25 instances, it also means I could scale the instances up to 50 or add more micro-services on a single machine. What do you think excites the Chinese developers working on Alibaba services? What happens if you develop not on a iMac, but instead on a laptop machine, MacBook Pro retina? Suppose you are disconnected from the Internet for hours on end or work in a remote location?

“I state for the record that I hold no grudge against Microprofile.IO project, I just believe that it is lagging behind the success of the Spring Boot project”

So these ruminations, I believe the Microprofile has to jump immediately in Java 9 and modularisation. I am not sure if WildFly is already there with JDK9 support, but I would like to think that some of the smaller players like KumuluzEE and Tomitribe can get there faster and with more agility. Other than GlassFish 5, there are no other certified Java EE 8 production application servers. I state for the record that I hold no grudge against Microprofile.IO project, I just believe that it is lagging behind the success of the Spring Boot project. I think Microprofile is best thing to happen to the future EE4J standard, now that an Oracle led and JCP defined Java EE 9 is non-existent. I also believe solving the Java 9 and enterprise edition platform support and integration is where Microprofile can catch up, improve and get strategically ahead of Spring Boot. If the vendors behind Microprofile initiative can do that, then happy days will be orange and great. So here’s hoping for it in 2018!





