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.
You can still join the specification itself as an expert or a contributor. You can do that via the JCP page for the specification.
You can have your JUG officially support the standard through Adopt-a-JSR.
You can share ideas and feedback, possibly by entering issues in the public issue tracker.
You can read the public review specification now.
You can try out the reference implementation now.
You can write or speak about Servlet 4 now.
You can encourage others to participate.
The next step is up to you. You can be a real part of Java’s ongoing success. If you have any questions I am happy to try to help – just drop me a note any time.
“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):
You can still join the specification itself as an expert or a contributor. You can do that via the JCP page for the specification.
You can have your JUG officially support the standard through Adopt-a-JSR.
You can share ideas and feedback, possibly by entering issues in the public issue tracker.
You can read the draft specification now.
You can try out the reference implementation now.
You can write or speak about the API now.
You can encourage others to participate.
The next step is up to you. You can be a part of the effort to keep moving forward the popular JAX-RS specification. If you have any questions I am happy to try to help – just drop me a note any time.
For those unaware, Vaadin is a popular GWT based RIA Java web framework. You may also be surprised that the Vaadin community is 150,000+ strong. To better understand this community the Vaadin folks fairly recently ran a survey. One of the things the Vaadin folks wanted to know is how often Java EE is used compared to alternatives. The results of the survey certainly look encouraging for Java EE, particularly given the seemingly perpetual nay-saying around Java and Java EE in predicable corners of our ever “colorful” industry.
The results for Java EE usage are shown in the graphic below. The most number of respondents – 41% – identified themselves as Java EE users. I think this is truly remarkable for a mature open standard like Java EE with a number of non-standard product vendors aggressively positioning themselves as competitors to Java EE for many years now. The relatively sizable 27% of respondents that indicated “other” is also quite interesting. It is possible these folks simply use Vaadin as their primary server-side toolset.
It is important to note though that the sample size is significant but small – 250+. That said, the survey is very reliable in one very important way. The survey was not anonymous/online but was from known and clearly identifiable members of the Vaadin community. This certainly helps reduce but not completely eliminate possible self-selection bias in an online survey. It’s also remarkable how similar these results are to other larger surveys from reliable, neutral sources (the DZone survey results are in the graphic below). The survey illuminates some other interesting but somewhat predictable findings – I would encourage you to look at the entire survey results.
While the Java EE platform has long included JSF as it’s primary web framework, I personally know of a good number of folks that actually use Vaadin with Java EE. Indeed I’d say it is one of the best if not the best RIA web framework out there (although I must admit I am a fan of PrimeFaces as an alternative to mucking around with JavaScript). It is really nice that Vaadin has long included strong support for Java EE.
While all of this is good news, the Java EE community can ill afford to rest on it’s laurels. The community has hard work ahead of it as always to continue to serve developers of all stripes. On behalf of the Java EE Guardian community it is only correct to thank everyone that indicate their support for Java EE in such surveys. Our volunteer driven work is intended to benefit you first and foremost – it is good to see that intent does not get lost in the muddle.
The Java EE Security API 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.
Java EE security is one of the most anticipated changes in Java EE 8. This is the case particularly because security is one of the last areas left to be revamped in the way most other Java EE APIs such as EJB 3 have been changed radically. As a result Java EE security is very highly dependent on things like vendor-specific GUI console wizards, vendor-specific configuration or command-line administrative tools. Pluggability, extensibility and customization is also currently challenging when the security features that already come with the application server are not sufficient. This is the main reason for the existence of third-party security frameworks in server-side Java like Shiro and Keycloak. The Java EE Security API aims to solve these important issues and promote both simplicity as well as portability, particularly on the cloud.
The best way to learn more about what is in the specification is looking at the specification draft itself. Another great way to get yourself familiarized is looking at the slide deck from key expert group member and my friend Rudy De Busscher (please click here if you can’t see the embedded deck).
While the specification is going to finalize soon, there are still plenty of reasons to get involved. Indeed this has been one of the most heavily community driven Java EE 8 specifications. 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):
You can still join the specification itself as an expert or a contributor. You can do that via the JCP page for the specification.
You can have your JUG officially support the standard through Adopt-a-JSR.
The next step is up to you. You can be a part of the effort to simplify and improve security in server-side Java. If you have any questions I am happy to try to help – just drop me a note any time.
Besides simply asking about Java EE 8 features, we asked a number of fundamental questions towards the end of the survey that go to the core of Java EE itself. 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 One of the most important fundamental questions we asked is around the complex relationship between standards and innovation. This question and its responses deserve a particularly in-depth look.
Here is how we phrased the question:
“Innovation and standardization is a tricky balance. Standards are pervasive, heavily relied upon and often strongly backwards compatible. For these reasons standards generally only include clearly proven ideas and avoid unproven ones. One can argue EJB 2 Entity Beans were an unproven innovation that was standardized too quickly. The Java EE ecosystem can always innovate ideas that are later standardized when proven.
That being said, standardization is an engineering activity and inevitably includes some level of innovation. It may also be the case that Java EE is different in terms of an open standard as it heavily competes with non-standard technologies.
How should Java EE approach innovation?”.
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. The most number of respondents (43%) essentially agreed with long-standing Java EE expert group consensus. Specifically this means taking a relatively conservative, organic approach to standardization. A further 14% favored a very conservative approach to standardization, forming a significant but not overwhelming majority. About 21% respondents had essentially the opposite view, equating Java EE with non-standard products. For context, this would basically mean standardizing features in products that are rarely used even by their own users. A further 23% favored a slightly more conservative approach that is still OK with standardizing ideas that are yet unproven. For context, these are most 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 and reactive programming as prominent examples; if you haven’t done so already, I highly recommend reading the linked article).
People that put in comments for the most part supported the existing Java EE approach to standardization. Here is a representative sample:
“Focus on reliability and long-term planning, Java is the backbone of many enterprises”
“I do not believe that Java EE should introduce any wildly new concepts or approaches”
“Stability is way more important than college kids’ untested and unproven ideas”
“Considering the purpose of Java EE in the first place, only those innovations should be considered that reduce bugs, increase stability, keep backward compatibility and reduce cost”
“The most valuable thing about Java is that it’s backwards compatible, so innovations should be standardized very carefully. Innovations are to be provided by libraries, frameworks, etc”
“I firmly believe in Java EE as a robust, reliable, base stack upon which to build the rest of your tech stack. As such, I don’t really think innovation should be seen much in it’s purvey. Let third party libraries, frameworks, and vendor-specific features take charge of innovation. Meanwhile, the Java EE specs should keep making sure to standardize as much of the proven ideas as possible to allow communities to disengage from specific implementations as much as possible”
“I see standardization as a final step of a lengthy engineering process. Changing a standard after it gets established is always difficult and if it is frequently required, it’ll be quite counterproductive”
“Since standards are there to last at least for a few years, I prefer a more conservative approach”
“It is important for Java EE to try to limit it’s scope only to proven ideas and make them standards. For all other ideas there is always the possibility to evolve as open projects and once they prove they are good Java EE can adopt them”
“Our industry is full of hype, it is a decease. Java EE should be free from it”
“Let the industry innovate…then standardize later. Don’t discourage the use of non-standard libraries”
“For me, standardization is a refining activity, which means to take the best approaches and bind them together in a way that makes sense and eases developers’ work. Innovation for innovation’s sake is not worth the effort since it takes resources away from other areas that need improvement”
“Java EE should be conservative”
“Innovations may be provided by vendors, no need to standardize them”
“One of the selling points for Java EE is the stability and robustness. If we start to introduce the innovation-of-the-day into Java EE, then we will threaten that stability”
“There can be innovation on top of Java EE. Once they are proven – and if found necessary – they can be included as standards later on”
“I’m all for new ideas, but if they’re going to make it into Java EE, the reason needs to be that people actually need them. Not just because X is the latest buzzword”
Java EE Innovation Approach in Context To understand the real significance of the current implicitly conservative approach to Java EE standardization, it is important to have some context.
I don’t think it surprises ordinary enterprise developers that technology vendors do not behave very responsibly when it comes to hype. Although there are a few brave souls, many do not have the correct incentives to self-regulate responsibly against hype. Even the ones that actually do have some good intentions are often slaves to their own egos, groupthink and isolation from down-to-earth blue collar enterprise development. Indeed grossly exaggerating the real world applicability (and consequent profitability) for startup(ish) ideas has become a such a habitual problem in Silicon Valley in recent years that it has long been hard to find companies that don’t do it (if you haven’t read the book “Disrupted” I highly recommend you do it soon). Quite frankly typical conference speakers, self-declared “industry analysts/thought leaders/opinion makers” and a certain class of consultants aren’t any better at any of this either.
As the Hype-Driven Development writeup author correctly points out, the ultimate safeguard against hype is ethical, responsible, business-value-focused developers that see the wasted effort, inflated costs, ongoing maintenance complexity and outright project failures that constantly chasing hype causes. Open standards, as an insulator between end-users and vendors have an important role to play as well. Indeed the many non-vendor independents in Java EE JSRs that I’ve had the honor to work alongside for years have long guarded carefully against hype. They understand well that guarding against hype and promoting long-term stability/simplicity is one of the most valuable things open standards can uniquely provide by encouraging direct early participation from real end-users as key stakeholders in Java EE expert groups. It is no coincidence that the worst standardization mistakes in Java occurred in the J2EE era when expert groups were almost exclusively vendor dominated. EJB 2 Entity Beans and an overzealous emphasis on EJB remoting/distributed objects were the key HDD ingredients of their day (indeed there are far too many stark parallels between distributed objects and microservices – it’s almost as though our industry is choosing to stubbornly forget the hard-earned lessons of the past :-)).
Often the only real way of getting things right is taking the lessons of past mistakes to heart. I think for many years now that has been true of Java EE. Most of the key changes in Java EE 5, Java EE 6 and Java EE 7 have been about standardizing ideas that have already been reasonably established. This includes standardizing JPA based on Hibernate, TopLink and JDO, standardizing CDI based on Seam, standardizing Bean Validation based on Hibernate Validator and standardizing JSF features based on RichFaces, PrimeFaces, OmniFaces, Seam Faces and DeltaSpike. The great lesson Rails had to teach Java EE is that it is OK to be a highly opinionated framework that wholeheartedly embraces the integrated platform concept and convention-over-configuration. Java EE 5 took those lessons to heart and frankly the Java EE community still enjoys the real benefits of those changes in a way few other communities do even today (and as many of us understood from the start neither Ruby nor Rails “took over the world” but instead found their own comfortable space for success; many of us in the Java EE community view Node.js in the same light today despite the tiresome hype now).
There have of course been some well-vetted organic innovations in Java EE as well. Examples include using annotations as metadata in EJB 3, declarative style service endpoints in JAX-WS, JAX-RS and WebSocket, CDI @Observer, @Stereotype, @Decorator and InjectionPoints as well as EJB 3 @Asynchronous and @Schedule. Some of us find it more than a bit ironic that many of these changes are actually quietly adopted later by frameworks that position themselves as rivals of Java EE but simultaneously claim a veritable monopoly on innovation in server-side Java…
By contrast there has been hype that the Java EE expert group has chosen to bypass, I think for the better. SOA is a fairly clear example. Even at the height of SOA hype, Java EE essentially kept SOA specific features at arm’s length, limiting it to the basic ability to publish SOAP endpoints using JAX-WS. Thankfully Java EE never over-reached into the inevitable quagmire of ESBs, enterprise integration frameworks or the WS-* family of specifications. The only small step in this misguided direction ended relatively expeditiously with the pruning of JAXR in Java EE 6.
I know my saying so will not sit well with some of my fellow Java EE expert group members, but another good example is Java EE largely bypassing OSGi hype. It was obvious from the start that the complexity of the OSGi model/runtimes coupled with the complexity/needlessness of trying to modularize most real world applications was bound for failure in the blue collar enterprise (does anyone still even remember Spring Dynamic Modules or SpringSource dm Server?). Java EE ended up making no changes to try to accommodate feverish OSGi hype of the day. What happened was far more pragmatic. With the notable (and unfortunate) exception of WebLogic, Java EE vendors modularized their runtimes instead – performing a very difficult ground-up rewrite few other non-trivial software projects would have likely survived. I think a particularly brave shining examples of this is WebSphere Liberty. IBM could have just stopped at embracing the Web Profile via WebSphere Classic. Instead they chose to simultaneously embrace the Web Profile, a total rewrite and ground-up modularity via WebSphere Liberty.
This complex and nuanced context is why some of us raised an eyebrow when we saw some of Oracle’s Java EE 9 ideas. Frankly it is the reason the question on innovation and standardization showed up in the survey at all. Some of the Java EE 9 proposals look more along the lines of the past mistakes made in the name of vendor-driven innovation/time-to-market concerns of the J2EE era than the more measured, community-driven standardization of the Java EE era. Conversely, this is also why most Java EE folks see the critical value in the MicroProfile effort and projects like WildFly Swarm that innovate with Java EE and serve as pipelines for standardization of proven concepts.
Java EE as an Enabler of Innovation This discussion will not be complete without some understanding of the fact that Java EE does far more than simply passively standardize proven changes. Java EE actually seeks to enable innovation in more fundamental ways than most seem to know or wish to acknowledge.
There is a curious charge out there that Java EE somehow discourages innovation by insisting that developers only use standard APIs and only the platform. At best this is a grossly outdated idea that persists from the J2EE era fueled by ignorance. At worst it is a bit of deliberately designed anti-competitive propaganda.
The reality is that Java EE has long done it’s best to promote innovations through plug-ins, extensions and conservative standardization. Every expert group in virtually every Java EE JSR works hard to make sure Java EE APIs have ample extension points that both the community and vendors can use. Some obvious examples include the CDI portable extensions API, CDI interceptors, Servlet filters/listeners, JAX-RS interceptors/filters, JPA unwrap methods, the JSF component model, the WebSocket programmatic API, WebSocket encoders/decoders, Bean Validation custom constraints, JCA connectors and many more. The clearest message of the active encouragement of ecosystem innovation that builds on the platform comes from the very charter of Java EE from years past now:
“It would not be appropriate for the Java EE platform to grow without bound to include all the interesting and useful technologies desired by web and enterprise application developers. Instead, we believe it is desirable to enable more of these technologies to cleanly layer on or plug in to Java EE application servers. By adding more extensibility points and more service provider interfaces, these other technologies can plug in to platform implementations cleanly and efficiently, and be just as easy to use for developers as the facilities that are built into the platform”.
These are the capabilities and underlying philosophy that powers projects like Seam, Arquillian, DeltaSpike, PrimeFaces, OmniFaces and so many more. Indeed these capabilities power the very products that aim to position themselves as alternatives to Java EE.
The Java EE platform goes farther than simply provide extensions. It has long been the case that almost every Java EE API is also available outside the platform in a standalone fashion. This is the case despite the fact that these APIs target Java EE in their JSR charter, closely integrate with other Java EE APIs, coordinate heavily with the Java EE expert group both in terms of schedule as well as content and are often directly funded/staffed by product teams that provide commercial implementations of the Java EE platform rather than an individual API. These standalone parts of Java EE can be used basically in any way anyone can imagine. This takes substantive hard work and real investments that even the most aggressive competitors to Java EE can and do routinely take advantage of. A good friend and fellow Java EE expert group member once asked me “why do we do this to ourselves?”. The answer is that it is the right thing to do in order to promote innovation and extend the value of Java EE to the ecosystem far beyond the boundaries of just those folks that embrace Java EE as a cohesive platform. The hope of course is that some of the resulting innovation would make it’s way back to the platform. There is no other platform, standard or otherwise, that goes to such lengths to empower innovation in a very broad ecosystem. Failing to properly acknowledge these facts does serious disfavors to the very ecosystem that benefits from Java EE.
I do hope this post serves as food for thought in the complex topic of Java EE, standards and innovation. Please do stay tuned as I further look at a few more similarly fundamental 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.
