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.
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
JavaOne 2017 will be remembered for the surge of interest in Java 9 modules and migration
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.”
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.
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?
- Spring Boot compatible layers and library component integrate very well with each
- Widespread annotation configuration and conventions
- No XML required, if any. Developer prefer YAML files for configuration
- Works with Tomcat, Jetty or Undertow
- Well designed Metrics library
- Many developer already have familiarity with other existing Spring project components: IOC, Data, Web, MVC, REST, Security, Integration, Social etc
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.
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
- Retina 5K Display
- 3.8GHz Processor
- 2TB Storage
- 3.8GHz quad-core 7th-generation Intel Core i5 processor
- Turbo Boost up to 4.2GHz
- 8GB 2400MHz memory, configurable up to 64GB
- 2TB Fusion Drive1
- Radeon Pro 580 with 8GB video memory
- Two Thunderbolt 3 ports
- Retina 5K 5120×2880 P3 display
- Total cost:£2,249.00
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.
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.
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!