Over a million developers have joined DZone.

Spring, Java EE, and the Lilliputian Wars

DZone's Guide to

Spring, Java EE, and the Lilliputian Wars

The battle between Spring and Java EE might be just as important as the Lilliputian wars. In the end, they share common goals and are not that different, are they?

· Java Zone
Free Resource

Build vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!

“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 bystander 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 18th-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 pettier 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 its 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 its 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 further 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 saddest 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.

Build vs Buy a Data Quality Solution: Which is Best for You? Maintaining high quality data is essential for operational efficiency, meaningful analytics and good long-term customer relationships. But, when dealing with multiple sources of data, data quality becomes complex, so you need to know when you should build a custom data quality tools effort over canned solutions. Download our whitepaper for more insights into a hybrid approach.

java ee ,spring ,java ,oracle

Published at DZone with permission of Reza Rahman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}