One of the most important things to continue to do for Java EE/Jakarta EE is highlight successful adoption stories at a regular cadence. The community has been doing just that for a long time. A number of these stories are curated here. In this vein, Hamed Hatami graciously agreed to share his Java EE adoption story. Hamed is a very experienced early adopter of Java EE that has developed a number of mission critical enterprise applications in Iran and now Sweden.
Can you kindly introduce yourself? My name is Hamed Hatami and I graduated in Software Engineering from the Azad University of Iran in 2000. I started to work from the last year of my university with various programming languages and frameworks. I have worked for many well-known organizations all around Iran like the Informatics Services Corporation, the Social Security Organization and many others. I have had a lot of responsibilities such as a Software Developer, Software Designer, Technical Team Leader, Technical Consultant and Software Architect.
I have known the Java programming language since 2000 and I fell in love with it right away.
I was the technical leader of many national projects developed with Java EE such as the RTGS–ACH–Chakavak (check management system) for the Central Bank of Iran.
I have a lot of hands-on experience with Java EE technologies like JSF, CDI, PrimeFaces, RichFaces, EJB 3, JPA, Hibernate, EclipseLink, JDBC, JAX-RS, JAX-WS, JAX-B, JSON-P, JMS, ActiveMQ, HornetQ, WebSphere MQ, JBoss EAP, WildFly, GlassFish, MicroProfile and WildFly Swarm.
I am living in Sweden now to learn more in an international environment. Currently, I am working for Cyber Design Nordics as Senior System Architect and I also have another role in Ericsson Corporation as a Contractor.
Can you describe the applications that use Java EE? What does your company do? Most companies that I worked for are in the Banking and Insurance domains. There are many technical challenges in developing systems for such companies because of the large number of concurrent users and the large volume of data. For instance ACH had to process more than 80 million transactions per day. The Real-Time Gross Settlement (RTGS), Automated Clearing House (ACH) and Check Management System (CMS) for the Central Bank of Iran were developed on Java EE 6 technologies.
Since I came to Sweden, I have been working for Cyber Design Nordics and I have designed and developed two enterprise systems based on Java EE 7 for one of the most famous companies here. Nowadays I am working for Ericsson as a Contractor with the Java EE stack.
Besides these, I have produced a few products myself with Java EE 6 and Java EE 7 like Magnolia Bus, Magnolia ATM Monitoring, Magnolia Dynamic Report Designer and Magnolia Central Authentication and Authorization.
Why did you choose Java EE? As a matter of fact, I have been a big fan of Java EE for a long time.
I think I was one of the first people in Iran that developed many web applications based on Java EE 5 and JBoss Seam which was a rival for Spring IoC in those days. As a result I had good knowledge of CDI and its advantages from the very first release.
I believe in the Java Community Process (JCP) and the open collaboration of many companies like IBM, Red Hat and so on.
As you know, one of the most important things in software development is Rapid Application Development (RAD) and I think Java EE covers it well. With Java EE each block of your software architecture fits perfectly together.
Each Java EE Application Server has many services included like the Servlet container, the EJB container, the JMS container, transaction management, security modules, Administration Console for monitoring and tracking, etc.
Most high profile projects in enterprises with a large number of concurrent users and large volumes of data need very good software infrastructure and very good architecture to meet non-functional requirements. I think the Java EE ecosystem is designed to handle non-functional requirements like fault-tolerance, fail-over, reliability, scalability, high-availability, security, interoperability, stability and maintainability in the best way possible out of the box.
Because I have had many good experiences with different enterprise projects using Java EE 5, Java EE 6 and Java EE 7, it has become a default choice for me.
How do the applications use Java EE? As I mentioned before, most of my projects are designed and developed based on Java EE from scratch. In the presentation layer, we usually use JSF with a combination of PrimeFaces, RichFaces, JQuery, ZK and Vaadin with CDI. In the business logic layer, we usually use EJB 3. In the data layer, we usually use JPA/Hibernate.
More recently I have tried to use other platforms such as Dropwizard and Vert.x in some cases. What was your general experience with Java EE? Would you choose it again? I have had very good general experience with Java EE such as the many national projects that I mentioned, so I will use it again with new brand features in Java/Jakarta EE 8 and new innovative platforms like WildFly Swarm, MicroProfile and Payara Micro.
How can people contact you if they have questions? I am always available via email and LinkedIn.
In this entry I want to share some high level observations with regards to the renaming of JavaOne to Oracle Code One, mention my accepted sessions at Oracle Code One and highlight important Java EE content at Oracle Code One.
Overall Observations Some of you may already be aware Oracle has decided to rename JavaOne to Oracle Code One. Like many people in the community and for a number of reasons when I came to know of this I must admit I expected the worst with regards to Java EE content specifically and Java content generally. Nonetheless, I am not one to base judgements on sentiments alone but wanted to see in terms of concrete numbers how the renaming played out. An important data point in this regard is the makeup of the content compared to the previous few years of JavaOne. Another important bellwether is the number and quality of submissions (more on that a bit later). I am relieved to say the worst did not come to pass – at least for this year. I’ll explain why.
Overall the size of the conference in terms of content has remained the same or grown slightly. There is no question the number of Java related sessions has declined, but the decline is modest. Indeed there was a similar modest decline last year when Oracle introduced the “Oracle Code” track at JavaOne – short of an outright rename of the conference. It seems JavaFX and NetBeans has experienced the sharpest decline of content. There is also no denying a prominent presence for various Oracle centric content in Oracle Code One such as Oracle Cloud, Oracle JET, GraalVM, Fn Project, Oracle DB/MySQL and so on. In fairness, Sun did some of this too in its heyday albeit in a measured way with SPARC/Solaris, MySQL, ZFS, etc content at JavaOne. There are certainly major vendor conferences that seem to be entirely comfortable with throwing all semblance of impartiality out the window. I honestly don’t think that is true of Oracle Code One just yet.
Indeed Java EE content is certainly a bright spot. Despite a decline in overall Java content, the amount of Java EE content has remained basically the same. For context, Java EE generally occupies 10-15% of the content or about 50-60 sessions. I’ll describe the highlights of the Java EE content in a moment.
The most important point however is this – renaming or not Oracle Code One remains the top destination for both Java and Java EE content. And I say this as someone that firmly believes Java is strong enough to have it’s own distinct conference and I loved the fact no other conference in the world came even close to matching JavaOne’s Java content in terms of quality or quantity. Despite the decrease, the Java and Java EE content at Oracle Code One still outstrips the closest contender Devoxx Belgium by a respectable margin. While it has been great to see the EclipseCons add quite a bit of Java EE content this year, they do still lag behind the Java EE track at Oracle Code One. It is important to note though that if the current trajectory remains EclipseCon Europe will be the second most important destination for Java EE content, perhaps outstripping Devoxx Belgium. It is also the case that if a further decline in Java content remains a theme for Oracle Code One conferences like Devoxx Belgium and EclipseCon will be in a position to legitimately become the de-facto premier destination for Java and Java EE developers. I am, though, rooting for Oracle Code One. I would hate for the rich heritage of JavaOne fade away entirely. I would rather see JavaOne live on in spirit inside Oracle Code One.
My Sessions I am happy to say I have four accepted sessions total at JavaOne. Similar to the amount of Java EE content, that is about the same historically for me in terms of accepted sessions. Here are the sessions:
What Is CQRS+Event Sourcing and Why Should Java Developers Care? In this session I am explaining the architectural patterns of CQRS and Event Sourcing. I’ll also be showing through code why Axon is a great way of implementing these patterns in a Java application. Lastly, I will be touching upon why these proven patterns are important for microservices. By then, I hope to mention official Axon support for CDI that I am currently incubating for a few more days on my personal GitHub repository. Although I will be doing some tweaking, the current slide deck for this talk is here.
Eclipse MicroProfile: What’s Next? This is an evening birds-of-a-feather session primary led by Ken Finnigan of Red Hat and Emily Jiang of IBM. If you want to get the inside story on MicroProfile and Jakarta EE or want to get heard, I seriously suggest you attend this session. I doubt we will have many slides, but we should be discussing issues and ideas that really matter as long as the right audience makes the time to show up.
From Monoliths to Pragmatic Microservices with Java EE In this lab we will be discussing the fundamental value proposition of microservices and what the Java EE ecosystem offers today in terms of developing microservices. We will start with a Java EE monolith, break it up using just vanilla Java EE thin wars, then apply fat-jars/hollow uber jars/Docker and finally apply some MicroProfile features. I will very briefly talk about where something like Axon fits in the overall picture too. I am honored to co-present the lab with Ondro Mihalyi and Ivar Grimstad. There is quite a bit of tweaking to do, but the current rendition of the slides are here. The current lab materials are here.
Effective Docker and Kubernetes for Java EE Developers In this session we will be talking about various considerations for running Java EE applications on Docker and Kubernetes such as: whether to use thin WARs, fat JARs, or hollow uber-JARs to effectively work with Docker repositories, layering, and caching; whether to deploy applications within images, through exposed admin ports or as autodeployed mounted external volumes; how Docker clusters, networking, and Kubernetes deployments align with application server administration, clustering, autodiscovery, and load-balancing; how the CI/CD pipeline of your application can be adapted to Docker and Kubernetes; and so on. This is a net new talk being developed with kind help from my co-presenters Ahmad Gohar and Hillmer Chona.
Java EE Content Mentioning all fifty some Java EE sessions is probably unnecessary and unproductive. I certainly would encourage you to explore the content catalog yourself, even if you don’t plan to come to JavaOne. In general the sessions can be put into two categories – API talks mostly focusing on the Java EE technology itself and more how-to style sessions that focus on how to apply Java EE technologies. I’ve highlighted sessions in both categories that I think are worth specifically mentioning. I would say there is a healthy mix of vendors and community as well as expected names and newcomers. I am particularly encouraged to see IBM, Red Hat, Payara, etc talking about MicroProfile and Jakarta EE, the WebLogic team talking about Java EE and Oracle staff talking about the new Java EE based Helidon project. I would say you should not miss these sessions.
With regards to the transition from JavaOne to Oracle Code One, I think a fair sentiment is “so far so good”. Beyond the content we will have to see how the rest of the conference goes in terms of venue, execution, vibe, community and most importantly attendance. I certainly will try to do whatever I can to support Oracle Code One. I hope you will consider attending, especially if you consider Java EE important.
While the content is definitely good, there is room for improvement, there is something we can all help move forward and that is where I would actually like to end this entry. From somewhat an insider standpoint, there are signs it was not easy for the organizers to select quality Java EE content. Tell-tale signs are repetitive material and certain speakers with larger number of sessions (and yes, I am including my own sessions in that observation). I suspect the quality and number of Java EE submissions was lower than it really should have been in JavaOne/Oracle Code One terms. If this was indeed the case, it is deeply disappointing because we should be fully standing behind the conference at least for now. One simple way to do this is adopt the ideas and content I have tried to share a few times already. In particular I think Oracle Code One could have used more content around various aspects of Java EE 8 as well as specific MicroProfile API/specification talks. This is something both vendors and community folks can do something about – and certainly beyond just Oracle Code One. If there is something I can do to help in this regard, I will be delighted to do so.
One of the most important things to continue to do for Java EE/Jakarta EE is highlight successful adoption stories at a regular cadence. The community has been doing just that for a long time. A number of these stories are curated here. In this vein, Vladimir Herman graciously agreed to share his Java EE adoption story. Vladimir is a young developer in the Czech Republic working on medical applications. He has experience with both Spring and Java EE applications. Thanks very much Pavel Pscheidl for helping facilitate the sharing of this Java EE adoption story.
Can you kindly introduce yourself? My name is Vladimir Herman and I am a Java developer in one of the largest Czech software companies. I started working with Java professionally in 2013, when I was still a student at the University of Hradec Kralove. I was employed as a junior Java developer in the internal IT department of an insurance company. That’s why I look at my career in two separate stages – during and after my studies. I have learned a lot from academic life as well as from practical work experience.
Can you describe the applications that use Java EE? In my previous job, we developed web applications in Java that were based on the Spring framework. In my current job, we are extensively using Java EE 7. We develop medical applications for foreign and domestic customers, such as ministries, hospitals or polyclinics.
The applications are mainly used by trained employees of these institutions. That means they are demanding customers who precisely know the problems related to the application domain. This greatly increases demands on the services provided by our system.
Why did you choose Java EE? The first contact with programming was completely different for me. At lower grades of my education I encountered procedural programming and languages such as assembler and C. I got familiar with the object-oriented paradigm through Java SE/Java EE at the university and I immediately thought it was the right choice for me.
One of the major benefits of Java EE is its comprehensive portfolio of technologies and APIs. Java EE is a mature technology, it has a diverse ecosystem as well as a very active community. It is also beneficial that you can extend the platform with various frameworks when needed.
The seamless integration of the individual parts of Java EE is invaluable. Integration is not always trivial and you have a very powerful tool in your hands once you grasp this concept.
We must not forget the benefits of the JVM itself. It is great to have a portable and platform independent runtime, considering the diversity of our customers.
How do the applications use Java EE? During my relatively short professional career, I was able to experience the development of Spring framework as well as Java EE technology stack applications.
The applications on which I work mostly follow a layered MVC architecture. Java EE technologies are used in all layers of the application. The main technologies in use are JPA, CDI, EJB, JAX-WS and JSF, but of course there are more. The vast majority of our applications are designed to be monolithic robust units that are self-contained. Individual applications are able to communicate with their neighbors using SOAP when needed, but we also run applications that use JMS. The resulting system can be thought of as composed of multiple large modules, but they are certainly not microservices quite yet.
I started working on an application based on J2EE 1.4 about a year ago. It is a key application for a few important customers and it has been in maintenance mode for many years. Developers were hesitant to make larger changes that could endanger existing functionality or would not be backward compatible. A recent breakthrough occurred when the application was bought by another customer. The application now needs to be rejuvenated as a result. Some of the technologies have become obsolete enough to be replaced outright and others were upgraded to the current version. One of the major changes was switching to Java EE 7 and replacing JSP with Facelets/JSF. Another crucial step was the introduction of DI through CDI. All changes were made with an emphasis on easier maintenance in the future. What was your general experience with Java EE? Would you choose it again? I gain experience with Java EE every day. Java SE 9 was released not too long ago. Java EE 8 brings changes like asynchronous events for CDI, HTTP/2 support in Servlet 4 and so much more. I am just in the constant process of learning, reading documentation and testing my knowledge in the real world.
I think there is a bright future for Java EE and I would certainly use it again.
I have also noticed the arrival of Spring Boot. It adds another layer of abstraction for applications based on the Spring framework but it is still a step in a good direction in my opinion.
How can people contact you if they have questions? The best way to contact me is by email at hermicz at gmail dot com.
DevNexus 2018 was held in historic Atlanta on February 21-23. For those of you not familiar with it, DevNexus is the most significant Java centric conference in the South Eastern US and now perhaps even at a national level. It was started by JBoss Java Champion Burr Sutter and organized by the Atlanta JUG (currently lead by Vincent Mayers, Pratik Patel, et al). I guess at this point I am somewhat of a DevNexus veteran myself. As usual DevNexus attracted a bevy of world class speakers including Ed Burns, Kito Mann, Sebastian Daschner, David Blevins, Ivar Grimstad, Rafael Benevides, Jeanne Boyarsky, Victor Orozco, Mohamed Taman, Roberto Cortez, Edson Yanaga and Enrique Zamudio. This was another solid year for DevNexus. Java EE had a strong showing at the conference as usual, including my own sessions.
I started the conference with my new all-day workshop titled “Pragmatic Microservices with Java EE and WildFly Swarm”. I start the workshop with trying to do the right thing in explaining what microservices really are, what practical value they offer for most of us and when you should consider them (or not). The hands-on portion of the workshop starts with running a so-called “monolithic” Java EE application on Payara (my plan is to port this code over to WildFly). We then separate a small RESTful service out of the application (a so-called “microservice”). At this stage, the microservice is a simple vanilla Java EE thin war also running on Payara. We then discuss the pros and cons of Java EE thin wars vs. fat jars as well as WildFly Swarm. The next portion of the lab runs the microservice as a fat jar using WildFly Swarm. We finish the lab by discussing concepts such as Linux containers (e.g. Docker), dynamic discovery, health-check, metrics, retry/circuit-breakers/bulkheads and client-side load-balancing. We see these concepts in action using the more advanced features beyond fat jars that WildFly Swarm offers.
The slide deck I use for the workshop is below (click here if you can’t see the embedded slide deck).
A webcast covering the more lecture-oriented parts of the workshop can be found here. The code and instructions for the workshop can be found on GitHub. I’ve deliberately designed the lab materials to be fairly self-guided so you can definitely use the lab materials on your own (or perhaps even run the lab in your own company/JUG) . You are always welcome to reach out to me when needed.
The next day in the afternoon I delivered my talk titled “Java EE 8 and Java EE 9 – What You Need to Know!”. I discuss continued Java EE adoption, the importance of Java EE to the ecosystem, the contents of the Java EE 8 release as well as the opening up of Java EE through the Eclipse Foundation. I also talk about the key MicroProfile initiative that aims to bring a collaborative, fast-paced, vendor-neutral approach to microservices in the Java EE ecosystem. The heart of the talk covers the key features of Java EE 8 such as HTTP/2, a complete security API overhaul, even stronger JSON support, support for HTML 5 Server-Sent Events (SSE), CDI 2, Bean Validation 2 and Java SE 8 alignment. The current slides for the talk are below (click here if you can’t see the embedded slide deck). Just as is the case for the lab, you are welcome to use the slide deck freely.
Later in the afternoon Ivar Grimstad did a deeper dive on MicroProfile. The same day Sebastian Daschner did a very cool talk on Cloud Native Java EE and Víctor Orozco did a talk on Java EE microservices.
The next day I volunteered at the Eclipse Foundation booth alongside Emily Jiang, David Blevins, Cesar Saavedra, Roberto Cortez and Ivar Grimstad. The booth featured both the MicroProfile and EE4J projects. Booth traffic was great and there was lots of interest in both projects. I finished the conference by attending Roberto’s excellent talk featuring awesome demos of Java EE/MicroProfile on Raspberry Pis.
Overall this was another great year at DevNexus and I hope to be part of the conference next year.
Servlet 4 has just posted a public review (this is the last step before the proposed final specification). Servlet 4 is easily one of the most critical components of Java EE 8. The primary aim of Servlet 4 is to bring first-class, core standards based HTTP/2 support to the server-side Java ecosystem. Most of the changes in Servlet 4 (with the exception of things like the server push API) should be transparent to developers and are enforced in terms of requirements for Servlet 4 implementations to fully support HTTP/2. A decent resource to learn more about Servlet 4 and HTTP/2 should be my slide deck (please click here if you can’t see the embedded slide deck). You are also welcome to check out the corresponding screen-cast here.
You can download and take a look at the draft specification itself from the JCP site. While this is essentially the final stretch for Servlet 4, below are some ways you can still engage (most of it comes directly from the Adopt-a-JSR page I drafted while still at Oracle). The Servlet 4 specification lead Ed Burns has also asked for specific help in testing out the server-push feature. His write-up is actually also a great introduction to the feature.
“Difference in opinions has cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether the juice of a certain berry be blood or wine.” – Jonathan Swift, Gulliver’s Travels
Gulliver’s Travels is one of my all-time favorite books. I read it twice from two completely different perspectives. In my pre-teen years I read it as a completely absorbing fantasy novel. When I read it again years later in my late teens, I began to realize what the classic novel actually was. It is a brilliant sociopolitical satire and biting commentary on the less than flattering parts of human nature – deliberately masked as a work of fiction in a time when such public commentary could cost you your life, liberty and happiness. Some recent events in our “colorful” industry reminded me of a particular lesson that Jonathan Swift was desperately trying to deliver to mankind. Bear with me. I think you’ll see the analogy.
Fragile Rays of Hope Sad as it may be, I think it has long been the case that people who choose to be outspoken advocates of Java EE and open standards accept some level of contention as an inescapable reality. You can try to hide from it, but beyond a certain level of visibility the contention is bound to find you in one way or the other. When I first decided to stand up for Java EE and open standards, I tried my best to hide. After some years I came to realize trying to hide actually isn’t a real choice if one cares about the long-term health of server-side Java. But neither is reveling in the contention. That’s a good indication you’ve lost your soul to the most malevolent parts of the contention.
During the most recent ongoing episode of the contention though something very unexpected happened for the first time that has given me a slim ray of hope pointing to a better future. The main point of this entry is to try to expand that tiny sliver to be as shiny of a ray of light as possible.
As largely a neutral by-stander of the recent contention, Lieven Doclo decided to write up his observations. For those that don’t know Lieven, he isn’t just a random developer. He is one of the small handful of long-time Spring ecosystem committers that isn’t an employee of the parent company central to moving Spring forward. He has always believed there is a distinct separation between the Spring community and any particular company working on the Spring codebase. This isn’t unlike what most of us believe in the Java EE community. One of the reasons we value Java EE so much is it’s relative separation from the likes of Oracle and IBM. Every sentence of his exceptionally written entry is well worth reading and thinking about, but I’ll highlight the most importance passages here for your convenience:
“The real issue at hand is the fact that both communities do not reflect the opinions of the commercial companies that have a vested interest in one of the approaches and that the way those companies conduct their businesses leaves a bad impression on all of us, tainting the way we look at each other. I’m a Spring framework user. I maintained (and still maintain) code that once was mentioned on the Spring website (Spring Rich Client). I have been a supporter for over 10 years and probably always will be. But do I support [Acme Company]’s below-the-belt hits to the EE community? No. Because it doesn’t serve any purpose except for promoting a commercial position, which I frankly don’t care about because I got into Spring for completely different reasons. Will I ever use EE? As a platform probably not, because Spring fills every need I have and I don’t see the point at the moment. Do I use EE specifications? Sure, I use JPA, JMS, JTA, … People need to realize how silly the fight really is. As developers, we’ve been blessed by not having one but two valid choices to build high-quality applications. And believe me when I say that there are much worse choices in the Java ecosystem to work with than Java EE or Spring. Instead of going at each other, how about we join forces and get rid of those in our industry?”
I debated for hours whether I should stop this entry here and let Lieven’s thoughts stand on their own. No one has ever said this before with such clarity, sincerity, courage and integrity. Lieven has pretty much told all of us what the way forward is – and I do mean all of us. There is not really much else to say. It is now up to us to listen (or not :-().
Unfortunately or fortunately I find myself compelled to say a few more things about the factors beneath the surface I think has driven the toxic contention for so long. I believe it is best to try to understand the darkness in order to succeed in banishing it forever. Maybe for some of us this will be a much needed part of understanding ourselves a bit better and putting these cancerous sores finally behind us (or not :-().
The Lilliputian Wars For the benefit of folks who have not had the pleasure of reading Gulliver’s Travels, I’ll briefly describe the Lilliputian wars. Lilliput was an island nation of tiny people that Gulliver had the misfortune of visiting in his travels. Gulliver found himself embroiled in a bitter war centered on what end of an egg should be broken to eat it. The great-grandfather of the current emperor had decreed that all eggs be broken on the smaller end after his son accidentally cut himself breaking the egg on the larger end. The problem is that Lilliputians until that point deemed it their religious duty to break eggs on the larger end. This led to many years of needless bloodshed and civil war, eventually even involving the neighboring island nation of Blefuscu.
What Jonathan Swift was actually describing is the early eighteenth century strife between Catholics and Protestants in Great Britain eventually leading to a very costly war between Protestant Great Britain and Catholic France (interestingly Swift himself was actually an Irish Anglican minister). The message Swift was trying to convey was that the religious strife of his day was petty and did not warrant the level of conflict, harm and animosity that it caused. By extension he was commenting on the petty but incredibly damaging rivalries that humans are prone to get themselves into. It is fairly clear Swift felt that the suffering brought onto ordinary people on both sides was at least in part fueled by Imperial power agendas and whims little to do with the actual common good or truth.
I hope you were paying attention to the passages I quoted from Lieven. Given what Lieven had to say, I think you get the Lilliputian war analogy now.
I will be the first to tell you Spring and Java EE have differences. Let me also be the first to tell you that the similarities for most immediate, short-term, common needs are far greater and have been for quite some time now. The level of negativity in the contention obscures this fundamental truth and maybe to some degree actually fuels it. As Swift probably observed, the sad reality of human nature appears to be that the more petty the differences, the more bitter and noisy the quarrel. Next time you decide to enter the Spring/Java EE contention you may want to ask yourself whether the differences you wish to highlight are really worth bitterly bickering over.
Old Grudges Die Hard The people that suffered the most from the Lilliputian wars actually had little to do with starting it. They were simply mindlessly continuing a well outdated legacy feud without actually evaluating it’s validity under current circumstances or letting go of their old grudges. As Lieven suggests, this too has strong analogs in the Spring/Java EE contention. The over-the-top, flamboyant negativity was birthed into existence by people that have now largely moved on but we are all left with it’s sad legacy. It is also far too simplistic to think the negativity is all one-sided (it rarely is; negativity has a nasty habit of begetting negativity in return). Indeed one can legitimately claim that there was a time the same kind of negativity that is currently being actively directed at Java EE had some equivalents from the Java EE side in the past. I must honestly say though that I think it was isolated, low-profile and not well-supported. No company certainly actively promoted it. Most of the people in the Java EE community did not stand behind it because we knew it was wrongheaded.
Whatever the realities of the past may have been, they lie in the past. Perhaps we should remind ourselves that “an eye for an eye will make the whole world blind”. We can’t change the past. We can however choose to let go of old grudges and focus on a brighter mutual future.
(This is a bit of an obscure reference but the photo is just great. It’s easy to envision Lieven as Bugs Bunny :-). To fully understand the reference, please look up “Hatfields vs. McCoys”) Ignorance is Bliss Part of the negativity definitely stems from genuine ignorance. As my fellow Java EE community enthusiast Tim Falconer puts it, the naysayers don’t seem to have bothered to revisit the validity of their assumptions for close to a dozen years. Technological ignorance aside, there are also more emotive issues rooted in the past including views that Java EE is large vendor-driven only, expensive, non-Open Source and so on. Like all ignorance, the antidote to this is greater exposure. These folks should set their pre-conceived notions aside and connect on social media to an actual Java EE user. Thanks to the continued organic growth of Java EE, such people are really not that hard to find these days. What you will likely find is that Java EE has evolved beyond recognition, forged through ever-growing real world adoption and grassroots community feedback over the past dozen years. Java EE is now more grassroots community driven than pretty much any other technology around. You can get outstanding open source Java EE implementations without paying a cent. There are tiny companies developing Java EE implementations alongside the largest companies in the world. And yes – Java EE is productive, easy-to-use, lightweight, Docker-friendly, cloud-ready and microservices capable. Just ask my friend and fellow Java EE enthusiast Adam Bien :-). None of this means you need to suddenly become a Java EE true convert. It simply means you probably should try and revisit your assumptions.
The Temptations of Negative Marketing The temptations of negative marketing really are very strong, especially under some specific conditions. The largest factors by far are the ones I’ve already mentioned. Once the negativity train starts full steam, it really is easy to just keep going mindlessly no matter what. To see this in action, all you need to observe is the US elections. As the nation gets further polarized, the more negative the campaigning keeps getting every year – perhaps reaching unthinkable levels in 2016. The thing is that most voters don’t actually see the negativity in a very good light, although there is always a polarized segment on either side that will mindlessly cheer on whatever outrageous negative thing “their” candidate has to say. Most just continue to distrust a candidate even after they “win” due to their campaign tactics. Unfortunately candidates themselves fail to realize this until it is too late because their closest supporters are true believers of the negativity.
We would be mistaken to think the same thing is not happening in Java. Though there are the polarized crowds in both the Spring and Java EE camps, most Java developers sit squarely in the middle. Whatever technology set they actually use, when asked about adoption or migration in survey after survey the solid majority (50-60%) indicate they value both and see a bright future for both. If we want to retain the trust of these people going negative is probably not the smartest thing to do.
Folks that actively engage in negative marketing often think they can mask their negativity as something harmless or even well-intentioned! In reality negative marketing is easy to spot for most people. If it is negative statements that are over-the-top, unprovoked, non-constructive, without much proof, seems inaccurate, obviously unbalanced, outdated or serves no other purpose than to try to put down the “competition”, it is probably exactly what it looks like.
Indeed negative marketing carries heavy risks for most businesses. If a serious debunking effort actually makes negative marketing intent crystal clear, a business can lose its goodwill with customers for a long time. That is because the strange thing with humans is that we care about fairness at an innate level. Scientific studies show that this surprising trait has been a key to our continued evolutionary success as a species.
A serious debunking effort was unlikely in the Sun era because of it’s idealistic but foolhardy culture of trying to be the “nice guys” by never confronting anyone no matter what. Oracle has a similar problem due to it’s top-down command structure that strongly encourages employee communication silence on most things. I think it is important to note that a significant debunking effort is far more likely today as the grassroots Java EE community quietly continues to gain steam. Indeed folks like Adam Bien, Sebastian Daschner and Antonio Goncalves have been tirelessly FUD busting for a while now. Most adoption since Java EE 5 is thanks exactly to these grassroots community efforts. One must also give due credit to companies like Payara and Red Hat for standing up on behalf of the Java EE community when needed.
It is wise to think carefully about whether negative marketing is really worth these kinds of risks despite it’s obvious temptations. On the other hand, there is far more to gain by extending a hand of genuine friendship and working together towards the shared bright future most Java developers really want. The Zero Sum Game This last likely underlying major factor fueling the toxic contention has actually been a Silicon Valley epidemic for the past few years. It is described extremely well by Dan Lyons in his excellent book “Disrupted” (if you have not read the book, I suggest you do so soon – especially if you work for a startup anywhere). The problem is that Silicon Valley has moved from a long-term revenue making business model to a model that has an unhealthy focus on cashing out quickly through IPOs and moving on to the next startup. In order to convince Wall Street of inflated IPO evaluations, “good enough” is no longer good enough. It is not enough to have a long-term but modest product market. Every company must pretend it will “take over the world” and drive all of it’s competition out of business overnight – whether that is actually realistic or not. Co-existence is no longer a choice. It is all or nothing all the time. Heaven forbid if you are an employee with stock options that has any doubt whatsoever of this totalitarian vision and mission. These kinds of irrational expectations make for unhealthy high-pressure conditions that will make otherwise decent people think, say and do things they probably otherwise never would.
The thing that so many of us appreciate about Java EE as an open standard is that co-existence is a built-in assumption. Java EE vendors know out-of-the-gate they are not going to be the only one dominating a market but must share the revenue space with other Java EE vendors. In fact Sun did more than that. It made virtually every Java EE API available standalone so that the server-side Java ecosystem would broaden even farther than simply Java EE platform vendors. Sun’s mindset was the opposite of zero sum – it was to expand the market as much as possible so that it can be shared harmoniously by as many players as possible. Oracle will need to continue this legacy of co-existence whether it is comfortable with this vision or not.
The strange thing is that the fundamentals of the cloud vision also actually favor co-existence. In order to really succeed in the cloud it is needlessly self-limiting to support only your own technology and your own cloud. It makes much more sense to support and promote as many decent technologies on your cloud as possible. It is even important clouds work well with each other. Trying to put down a technology just because you don’t fully control it and risking alienating the users of that technology hardly makes any rational sense in this world at all.
This I think brings me to the most important part of my write-up – the concrete way forward towards a far less dark and negative and far happier and brighter future together.
Can’t We Just Get Along? The fact that makes me the most sad is that we all know well how to get along together and avoid pitting ourselves against one another. There is no secret sauce. It is all tried and true practices that have been around for ages. Many established companies (unfortunately not the Silicon Valley startup types) have these practices written down in their policies in one way or another. In fact what I’ll suggest as a way forward for all of us (and I do mean all of us) is taken directly from the policies of a great company that I had the pleasure of working for some years ago as an employee. The owners of the company had a pretty blue-collar business but took real pride in what they did (the kind of pride I see sorely missing in the rat race of the corporate world). They drew their principles from the Golden Rule rooted in their deeply Christian background:
Definitely promote the strengths of your own favored technology. It should be possible most of the time to do that without even mentioning the “competition”. It is also important to acknowledge and try to improve the weaknesses of your favored technology.
Speaking negatively of the “competition” should never be necessary. Indeed it builds goodwill to mention the strengths of the “competition” every now and then.
It is inevitably sometimes necessary to defend your own favored technology. In these situations, pointing out the weaknesses of the “competition” is sometimes unavoidable. The worst case of this is when you are asked to do a comparison. Even then it is important to strive for fairness and balance the best you can. Most of the time it should actually be possible to defend your favored technology based on it’s strengths alone.
I think these are easy principles for anyone to keep in mind. I’ve tried to follow them for years even when I didn’t have to. I believe it has served me and others well. I really think this is all it takes for harmonious coexistence.
I hope this is some useful food for thought. It’s time we ended the toxic negativity on both sides and made real efforts towards a brighter future together. I think people like Lieven expressing their sincere thoughts gives us all the perfect opportunity. Let’s not let it go to waste this time. We can respect our differences but still do justice to our common goals. Catholicism and Protestantism have done it incredibly successfully for years now. There are no more turf wars, clergy attacking at each others’ beliefs or cannons being fired. The British and the French are such good enemies they can’t resist being friends.
Jonathan Swift would be proud and so would Gulliver.
“JSON has replaced XML as the de-facto data interchange format. Java EE has long had excellent support for XML through JAXP and JAXB. On the other hand Java EE 7 includes only a very basic programmatic API similar to JAXP named JSON-P.
Java EE 8 has been slated to include a minor update to JSON-P that incorporates the latest JSON standards such as JSON Pointer. In addition a higher level annotation based API similar to JAXB named JSON-B has been targeted for Java EE 8.
How important is it to strengthen JSON support in Java EE?”.
The following graphic shows how the community responded. Clearly the mandate for adding more JSON support to Java EE is extremely strong. Indeed this is one of the items supported the most strongly along with HTTP/2, security and Java SE 8 alignment. 62% said it is very important while another 24% said it is important – with a combined total of 86%. Only about 3% said it is not important.
Here are some representative comments from participants in the order that people filled in the survey:
“It is important to make JSON easy to utilize from Java EE, so JSON-B is an important addition to the platform. The enhancements to JSON-P would be nice to have since they are part of the JSON standards”
“It would help bring some order to the zoo of libraries for JSON in Java like Jackson and GSON. Anything that would help standardize the behaviors of those implementations would be a good thing”
“A more mature JSON-P, and the inclusion of JSON-B, are godsends for any Java code that needs to work with JSON data”
“Current frameworks, such as Jackson and GSON lack standardization, making them hard to work with”
“JSON rules the world when it comes to interchange formats. Java EE should make it a first class citizen”
Like most items, Oracle’s own Java EE 8/9 survey essentially mirrors our survey results. Indeed the Oracle survey serves to clarify nicely what developers are thinking. While JSON-B ranked high at 4.1, support for the JSON-P update was much weaker at 3.8. For context, in the Oracle survey 1 indicated “Not Important” while 5 indicated “Very Important”. This generally makes a lot sense. JSON-P was already a pretty complete API in Java EE 7 and the use cases for JSON-B are likely a lot higher than the lower-level JSON-P API. What is notable but not altogether surprising is the strong support in favor of standardization the JSON voting patterns represent. Java EE 7 and JAX-RS 2 implementations have long provided JSON binding support in non-standard ways – most notably through Jackson and EclipseLink MOXy. Nonetheless, developers have a strong desire to have standard Java APIs for JSON.
Fortunately Oracle decided to move forward both JSON-P and JSON-B in Java EE 8. Indeed both APIs are now rapidly nearing completion. If you are interested, a great way to start learning about stronger JSON support in Java EE 8 is by looking at a slide deck from Dmitry Kornilov. Dmitry leads both the JSON-P and JSON-B specifications. If you can’t see the embedded slide deck, please click here.
Please do stay tuned as I further look at specific topics in the survey. In addition to my write-up, I would encourage you to look at these survey results yourself and get involved in Java EE 8. You can certainly do so by becoming a part of the Java EE Guardians.
One of the most important things to do at this stage of the life-cycle of Java EE is highlight successful adoption stories at a regular cadence. The community has been doing just that for a long time including at JavaOne. A number of these stories are curated here. Luqman Saeed recently agreed to share his Java EE adoption story. He has developed a number of production Java EE applications in his native Ghana. Luqman had a number of insightful things to say about Java EE worth paying attention to. I have highlighted specific passages that really stand out.
He had quite a bit to say on some of the most recent episodes of Java EE naysaying in certain parts of our “colorful” ecosystem.
Can you kindly introduce yourself? My name is Luqman Saeed, I am a blogger and I run Pedantic Devs. I am the head of Finance and Administration for a plastic manufacturing company in Accra, Ghana. I learned programming as a hobby about seven years ago. I started with PHP and the Symfony framework.
Back then, just like today, I read a lot of FUD about Java, and being quite an unusual person, I decided to find out what made the language such a lucrative bashing victim. I got hooked and have been doing Java since then.
Why did you choose Java EE? What applications have you written using Java EE? I used to write just a few simple GUI applications, mostly with Swing – and later JavaFX – for my day to day work activities. But about three and a half years ago, things got serious when I joined my current company and realized it lacked a reliable human resources and payroll program.
I decided to develop one internally. After consultations with my CEO and other top management, we had the user requirements at hand. I weighed a lot of options for Java web application development. I got a myriad of opinions, with Spring being the favorite of all reviews I kept reading.
However, Java EE 7 had been released at the same time, and a post by Adam Bien on his blog (I think it had to do with the simplest EJB component), got me curious. So I downloaded the Java EE tutorials, the specifications I was interested in and started reading.
The more I read about Java EE, the more I got blown away by the simplicity and elegance of the platform. The more I also got convinced I had discovered the holy grail of Java software development.
After about six months (including a hiatus of about two and a half months), I got my payroll system ready and deployed on GlassFish internally. Everyone was happy. I have since then developed a number of applications for some other companies, all on Java EE. All very easy to do.
I am currently working on a larger more complex version of the HRMS I developed for my employer and using the JPA, Bean Validation, EJB, WebSockets APIs from the Java EE platform as well as Apache Shiro from Stormpath, the CDI extension Apache DeltaSpike and Dynamic Reports. I used Vaadin for the UI because it has a CDI add-on that integrates perfectly with Java EE and also writing my UIs in pure Java speeds things up. As anyone who pays attention knows, Java EE is quite large, and the beauty of it is you just use only what you need!
What was your general experience with Java EE? Would you choose it again? Like I stated above, Java EE was not only logical, it was also very straightforward to use. I just need an application server and a single Maven dependency to get things going. The powerful, type-safe dependency injection that acts as the glue of the platform is what really blows my mind.
I find it quite amazing that with a simple change of a parameter from ‘annotated’ to ‘all’, I can magically @Inject any object I create. Wow. The first time I read the CDI specification, I was like OMG this is it. Literally. It just works, to borrow the popular Ubuntu aphorism.
I have been using Java EE for a few years now and I will still choose it any day, any time. It is productive, expressive and powerful. I find myself being immediately productive. If I need to master something, I just go to the specification page, download it and spend a few nights reading it.
Some people have recently stated that they view Java EE to be “obsolete”. What do you make of that? I have recently been keenly following all the latest hype about “microservices” and the very negative campaign being led by some very interesting camps about how Java EE is obsolete, bloated and so on. Honestly I just laugh and go back to hacking on my Java EE projects.
I feel the people bashing the platform either are just marketeers or just jump on the fad of the day, really. I can run a Java EE application by simply adding all the APIs to the application and do a java -jar. But why would I want to build an application server when there is one put together by very smart and knowledgeable people?
Most of the “application server is obsolete” proponents try to make it look like using an application server is the only way to run a Java EE application. Or that the application server somehow gets in the way of implementing a microservice architecture.
With projects like WildFly Swarm, I can even do fat-jars with ease if I want to. But personally I don’t know why all the noise over microservices in the first place because to me it’s been around in one form or another since before I was born.
Java EE is a platform that is highly productive, expressive, powerful, open, easy to use, and very reliable. Java EE isn’t a “brand” per se, so the question of Java EE brand “fading” is for me a prima facie null question. If you ask me, Payara is a brand, WildFly is a brand, TomEE is a brand and WebSphere Liberty is a brand. I am just a lemme-mind-my-business happy Java EE platform user. I hardly have time to bother with the FUD.
I also occasionally have CS students from a private university come to do internship with me and I – you guessed it – teach them Java EE. Java EE may be “obsolete” in the imaginary world of some people, but there are people like me in the real world, that don’t talk much, because we are happy users of the platform.
How can people contact you if they have questions? I am more than happy to share my Java EE journey and experience with anyone. Just contact me and I will be more than happy to speak. Once again, I will choose Java EE any day, any time. It just works :-).
Besides asking about relatively straightforward Java EE 8 features, we asked a number of more complex, foundational questions towards the end of the survey. In the prior entry, in this entry and a subsequent few others I am going to take a closer look at some of these questions. I’ll then return back to looking at the more mundane Java EE 8 feature specific questions. It will be clear in a few weeks why this change of order is important at the moment.
The Question In the prior entry I looked at one of the most fundamental questions we asked – the complex relationship between standards and innovation. If you have not yet read the entry, I think it is a good idea to take a look as vital context to the current entry. In this entry I’ll explore the question we asked about standardizing microservices specific features in Java EE. This is a particularly important question that deserves a very in-depth look. It is certainly a question Oracle, vendors, the community and Java EE’s usual antagonists are paying a lot of attention to so getting this right for everyone is crucial.
Here is how we phrased the question:
“Microservices is a relatively vague term. It can be interpreted to mean decomposing a larger logical application into smaller independently deployable subsystems.
There are frameworks that claim to specialize in microservices and include features such as custom configured, self-contained executable jars (also known as “fat jars” or “uber jars”), metrics, discovery, circuit breakers and bulkheads. Java EE currently does not include such features but it may make sense to add them. It should be noted however that Java EE centric tools such as WildFly Swarm, Payara Micro, WebSphere Liberty and KumuluzEE do offer such features.
Keep in mind, there are some industry thinkers like Martin Fowler that have expressed doubt whether microservices make sense for most applications. Some other folks such as Adam Bien believe Java EE is already well suited to building practical microservices.
How should Java EE approach microservices?”.
The Results The following graphic shows how the community responded. It’s not realistic to think there would be a simple answer to a pretty complex question, but there are clear patterns. A sizable minority of 44% respondents want Java EE to standardize microservices specific features. The majority 56% however want to wait to standardize or do not want to standardize any further microservices features in Java EE. 27% believe Java EE already has sufficient support for building practical microservices applications. Though not entirely, my personal views most closely resemble this group. I’ll explain myself a bit more later in this writeup. I’ve also explained my views in this screencast. A further 25% believe Java EE should wait to standardize anything more until microservices are better adopted in the practical enterprise. 4% believe microservices is just hype and should simply be ignored.
To put some of this into context, the level of support for standardizing microservices specific features is much weaker than standardizing features such as HTTP/2, more JSON, Java SE 8 alignment, Java EE security and dynamic configuration (some of these items enjoy near 90% support). Indeed the level of support was higher for the Java EE MVC API that has now been decoupled from Java EE and is being led by the community instead of Oracle. The level of support for microservices is essentially in line with standardizing features such as NoSQL and reactive programming.
Digging a little deeper into the data, there is a high degree of correlation between folks that support more microservices features in Java EE right away and folks that equate Java EE to a product instead of an open standard or don’t mind standardizing concepts that would very likely be considered Hype-Driven Development (HDD) by most ordinary developers in the blue collar enterprise (the very readable, extremely unassuming and sensible HDD write-up tellingly includes microservices, NoSQL and reactive programming as prominent examples; if you haven’t done so already, I highly recommend reading the linked article). In effect these folks would not agree with the currently fairly conservative approach to Java EE standardization.
A majority of the people that put in comments essentially had a pretty ambivalent view of adding more microservices features to Java EE right now. Perhaps the folks that have decided to advocate microservices for a few years now without many reservations should pay heed to folks like these? Here is a representative sample of comments:
“I believe microservices hype will eventually die down”.
“The hype is already fading. Wait a little and it will be replaced with the ‘next big thing'”.
“Stop the nonsense with uber jars and let a Java EE server have configurations that let the application define what modules are needed”.
“The success of Java EE centric tools like WildFly Swarm will dictate the need, or lack thereof, for standardization”.
“Java EE is well-suited to providing microservices. I am not at all convinced that WildFly Swarm’s approach to service discovery, for example, is something that should be standardized – it makes sense in some use cases, but not others”.
“I would have picked standardizing fat jars from the first point. The others are just design patterns or good practices”.
“99% of applications won’t need this. Only very large internet scale companies need microservices. Java EE is mostly used for corporate internal web applications (at least in my experience)”.
“Although I agree that Java EE already provides the minimum tools to create microservices I think it would be important to make some de-facto guidelines and tools. In particular I think it would be important to have a well-defined standard for self-contained executable jars”.
“Let the container developers (JBoss, GlassFish, etc) work on this for another couple of years and let it evolve”.
“WildFly Swarm should be the example to follow, by letting the ‘just enough application server’ idea to settle”.
“I think the only big challenge is developing a how-to that integrates Java EE with a handful of other technologies to create a microservices architecture which is good enough for everyone else who’s not Netflix”.
“Much of microservices is hype and is already experiencing some backlash”.
“For me microservices is an architecture. I think that Java EE as a platform should not be seen as a framework that follows some specific architecture principles”.
“Let’s wait for MicroProfile and build something upon it”.
“JBoss like application servers already support modularity, which in many ways make servers lean. A similar kind of standards based approach will help anyone build microservices with their own feature sets enabled”.
“Microservices are excellent in some cases, but most enterprise systems don’t really need microservices. Combine cloud and application server in the right way and we have microservices in the cloud”.
“We should just tell developers/architects (or maybe just management) that we’re not all Netflix”.
“I agree with Martin Fowler that microservices are not already proven and also that they are not required for many applications”.
“I agree with Adam Bien. Supposedly ‘lightweight’ solutions tend to become heavy over time. I do think it is great to have options so having WildFly Swarm, Payara Micro, etc is a good thing”.
“Microservices are hype, but can not be neglected. The main driver is actually to get more control of deployment and of configuration for developers. Java should provide mechanisms for that, which would be helpful regardless of whether microservices survives”.
“I would argue that Java EE fits nicely with microservices as it is today. It is more an architecture choice of style if you find monoliths or microservices a better fit for you”.
“I agree with Adam Bien that Java EE is already well suited and also with Fowler that microservices may not make sense to most applications”.
“Application servers with minimum required modules makes sense, but standards are probably not required”.
“None of the projects I’ve worked on would have benefited from being decomposed into microservices”.
“Java EE already provides the tools for building microservices. I think it should only create new profiles for microservices which provide the principal JSRs”.
“Microservices are an architectural pattern, there is no need to standardize it in Java EE”.
“Java EE should not start to standardize all named features at once but maybe start with uber jars”.
“Time will bring more understanding and consensus as to what a standard should look like”.
“Java EE is already great for microservices development. Trust Adam Bien :-)”.
More Microservices Data Points I don’t think there is any denying the fact that Oracle’s own Java EE 8/9 survey was heavily (perhaps even solely) focused on microservices including the way the questions were phrased as well as the questions themselves (you should judge for yourself: the survey text and results are here). One would expect that support for microservices would be much higher in those results than our survey as a result. I don’t think that is what actually happened. Most of the very microservice specific features such as service health, circuit breakers and modularity/fat-jars ranked below average (that is below 10 amongst 21 items surveyed, in order of importance). Indeed most of the items that ranked above a 4 were pretty mundane items like HTTP/2, REST, JSON, security and configuration. For context, 1 indicated “Not Important” while 5 indicated “Very Important”. Items such a reactive programming, eventual consistency and NoSQL all ranked between 3.5 and 4.
Beyond our and Oracle’s surveys, there is another excellence source of reliable public data we can look at on microservices. The 2016 RebelLabs survey understandably started including questions on microservices. The graphic below shows the results of the survey. Because of the complexity of the question patterns are harder to see but I think it’s safe to say the results are mixed. After a few years of fever pitch hype, only 34% say they have moved to microservices. Of that percentage, only 40% said moving to microservices has had a benefit for them. In terms of total percentages, that’s only 15% of developers realizing a practical benefit from microservices. There are also a troubling data points – 18% of “early” adopters reporting microservices have made life harder for them. Most – 42% – have not seen any real benefit to adopting microservices. Of non-adopters, 32% already say microservices are not for them while another 56% are basically still on the fence.
I think this is hardly the results to thrill the veritable chorus of vendors and “industry thought leaders” unabashedly cheerleading microservices for a while now. Hype and Reality The fact that ordinary developers still continue to have mixed feelings about microservices is not a surprise either to me or most folks I know personally in the community. There has been and continues to be a steady stream of people duly warning against the hype. One has to give due credit to Martin Fowler. He was one of the earliest prominent folks to write about microservices but he is also one of the earliest folks to warn about the hype. I don’t think you can get any clearer about what is going on than saying “enough to get everyone’s over-hyped-bulls*#% detector up and flashing” or “the majority of software systems should be built as a single monolithic application”. There have even been some pretty brave folks on the vendor side on the equation. Ruby on Rails creator David Heinemeier Hansson wrote an excellent blog entry titled “The Majestic Monolith” that is well worth reading for all server-side developers. My friend and fellow Java EE enthusiast Adam Bien has even gone as far as to making a fairly bold prediction of a backlash against microservices and uber jars as soon as this year. There is plenty more around once you begin looking including some humorous but pretty insightful memes from ordinary folks.
It is safe to say like these folks, I don’t mind being called a microservices skeptic. While I’m sure it doesn’t help our egos much, I don’t think most companies have the same problems as Netflix, Amazon or Google (and yes, that includes most Fortune 500s). For the vast majority of applications out there, microservices seriously violate the YAGNI principle – the associated costs and complexities are just not worth it and never will be. My general rule of thumb for considering microservices for most real world projects is a team size of about 7-10 active developers.
For projects that can actually benefit from microservices, the “micro” part of microservices still violates the YAGNI principle. Indeed what makes sense is breaking these systems down into pretty sizable sub-systems with distinct sets of business users. An example would be a larger insurance system that is broken down into point-of-sale, data capture, underwriting, policy management, payments, customer service, reporting, archival, etc sub-systems. The reality is that many of us have been successfully developing both these types of “microservices” applications in addition to monolithic applications with vanilla Java EE for a long time now.
This pragmatic approach is far away from the CORBA-like remote objects most microservices proponents seem to have an infatuation with where you would see dozens if not hundreds of distributed remote services comprising an application like account service, product service, user service or order service. There are only a tiny handful of companies that actually benefit from this level of granularity. These are the types of applications that really need the features that are offered by products like WildFly Swarm or KumuluzEE beyond what vanilla Java EE already offers. I’ve explained all of this in a fair amount of detail beyond what I have the space to say here in the screencast I referenced earlier in this entry.
What Should be Done in Java EE? Whatever the right thing to do in Java EE is, Java EE vendors should not let microservices hype pass them by. They should absolutely make sure their Java EE centric products are microservices “buzzword compliant”. Part of the issue is that it will take a while for pseudo-technical people in IT decision making roles that nonetheless hold CIO, CTO, architect and development manager titles (some of us lovingly call these people “PowerPoint Architects”; I’m sure you know the type) to be able to separate the hype vs. reality of microservices. Some may only learn the hard way by experiencing project failures, cost overruns and maintenance headaches themselves. We have to be honest with the fact that Java EE is not completely immune from the need for buzzword compliance either. That said if Java EE capitulates every time the hype of the day came along, it would quickly lose it’s well-recognized core value proposition as a stable, backwards-compatible open standard that serves as a buffer against hype and minimalist core for broad ecosystem innovation (indeed this is precisely what went wrong in the J2EE era).
I really don’t think most of the features that Oracle is proposing for Java EE 9 really should be standardized yet. This includes things like dynamic discovery, metrics, circuit breakers, client-side load-balancing, eventual consistency and so on. Just as is the case with WildFly Swarm and KumuluzEE, at this stage vendors should be actively innovating with and building on top of Java EE for these sorts of features. Collaboration on microservices features through open source initiatives like MicroProfile is also an extremely good thing. This approach allows for the usability and applicability of these features to be much better understood and allows ample space for the ecosystem to fully innovate before any standardization takes place. Maintaining a product-first approach also means these features get to developers faster, as they need to meet (real or imagined) needs. Mutual collaboration through MicroProfile also allows for rapid standardization later when the time is right. On the other hand, if the microservices ambivalence now in conference talks like “Microservices for Mere Mortals” and “The Dark Side of Microservices” turns into a full-scale grassroots backlash down the road, these features need never be standardized in Java EE. I’d say the biggest problem now is that Oracle is not part of MicroProfile and does not have an open, collaborative microservices product plan outside of what they said they wish to do in Java EE 9.
None of the above means there aren’t features that shouldn’t be moved forward in the core open standard. There are plenty of more straightforward Java EE features that I think would be welcomed well by the community:
Features like dynamic configuration and OAuth/OpenID support have been relatively well-awaited, are reasonably well-understood would be useful for projects whether they are using microservices or not. Oracle initially considered these features for Java EE 8 but then appears to have deferred these features to Java EE 9 in order to deliver Java EE 8 faster (a welcome move).
Considerations to fully modularize the platform has been around since the Java EE 6 timeframe. The big practical hurdle to doing this was the fact that Java did not have a built-in module system. I have to be honest in that I think modularity is a bit of a Red Herring overused in the usual anti-Java EE rhetoric. I’ll write more about this in a slightly different context in the next few weeks but I don’t think modularizing Java EE is a practical issue when the average Web Profile implementation is 35-50 MB and the average full profile modern Java EE application server is 120-150 MB. Let’s remember that the commodity disk space these days is approaching the terabyte range and an average network speed of over 10 mpbs is really not that uncommon anymore (I do have to admit there continue to remain real disk size offenders such as WebLogic at 800 MB – 1.5 GB). That all said, Java SE 9 modularity makes modularizing Java EE along the lines of it’s already separated constituent JSRs a real possibility and something that would be welcomed by many. This feature does have a real use case in very resource constrained embedded systems/IoT use cases. Indeed much of this has been possible in modular application servers like GlassFish since the Java EE 6 time frame.
To go along with modularity, it would be useful to have additional profiles in Java EE. For example a very minimal Servlet-only “Core Profile” and a “Microservices Profile” targeting a simple, non-persistent but JSON-capable REST endpoint certainly makes sense. This is very similar to what was done with Java SE 8 Compact Profiles.
Similar to modularity, I don’t think fat-jars are as cut-and-dry as most people seem to think. In fact I think Adam Bien might be right that fat jars can prove to be an actual anti-pattern with Docker compared to Java EE thin war files with time. That said, embeddable containers have been advocated for a long time in the Java EE expert group. I do think standardizing fat jars would be welcome by many in the community. Again, most application servers other than WebLogic already have this capability now. They do have a legitimate use case when working with bare metal JVM based PaaS environments that make a separate server installation difficult.
Going forward, the positions in this section is what I plan to personally advocate in the Java EE expert group. That said, there is always ample room for learning more in our ever volatile industry and perhaps my views will evolve over time as things continue to move forward.
I do hope this post serves as food for thought in the complex topic of Java EE and microservices. Please do stay tuned as I further look at topics in the survey. In addition to my write-up, I would encourage you to look at the survey results yourself and get involved in Java EE. You can certainly do so by becoming a part of the Java EE Guardians.
JAX-RS 2.1 just posted it’s first early draft review. Because of the now accelerated Java EE 8 schedule, the rest of the steps towards finalization of the specification is going to happen very quickly.
As the release versioning indicates, this is a relatively minor JAX-RS release. However there are a few very important changes in the release both for JAX-RS users and server-side Java developers at large. Besides smaller grain items, these are the major changes in JAX-RS 2.1:
The introduction of reactive capabilities in the JAX-RS client API. This is largely based on the Java SE 8 CompletableFuture API but the way the changes are designed most JAX-RS providers will also provide native support for RxJava. In essence this change allows for far more robust asynchronous, non-blocking, functional and composable REST endpoint invocations via the JAX-RS client API.
The addition of HTML 5 Server-Sent Events (SSE) support both on the JAX-RS server and client side API. Jersey had long added such support in it’s proprietary API in the Java EE 7 timeframe. This change further improves HTML 5 alignment for JAX-RS and Java EE.
Although it is not included in the early draft review, JAX-RS 2.1 is set to add non-blocking IO (NIO) support. Unlike the Servlet API which supports both asynchrony and NIO, JAX-RS so far only added asynchronous support as of JAX-RS 2. The JAX-RS 2.1 expert group is now currently actively working on the changes for NIO support. It should make it into the next specification draft.
At the moment the best way to learn more about what is in JAX-RS 2.1 is looking at the specification draft itself. Page 81 of the document has a nice log of changes since JAX-RS 2. Pages 36-38 describe reactive client support. SSE support is described in pages 57-60.
While the specification is going to finalize soon, there are still plenty of reasons to get involved. Here are the many ways you can still engage (most of this comes directly from the Adopt-a-JSR page I drafted while still at Oracle):