Reza Rahman - Professional Homepage
blank Home Home | Navigation Site Map blank Resume | Projects | Blog | Downloads | Links | Contact

My ramblings on Java EE, Java SE and the crazy World of technology in general.

Friday, April 21, 2017

Servlet 4 Public Review Starts Now!

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 simply join the discussion without any ceremony by subscribing to the Servlet specification user alias.
  • 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.

Thursday, April 13, 2017

Spring, Java EE and the Lilliputian Wars

“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.

Monday, April 10, 2017

DZone/Java EE Guardians Survey Results: JSON

As some of you are aware, the Java EE Guardians and DZone jointly conducted a community survey to help determine Java EE 8 features prior to JavaOne 2016. You may also be aware that we shared the results of that survey with Oracle before the details of the renewed Java EE 8 scope was announced. Now is a great time to start analyzing those results a bit more. I've already done a high level summary of the results. I've also done a deeper dive into the responses for HTTP/2 and Servlet 4Java SE 8 alignment, security, standards/innovation and microservices. In this entry I'll take a look at the responses for strengthening JSON support in Java EE.

Here is how the survey phrased the question:

"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.

Tuesday, April 04, 2017

Java EE Adoption Story from Luqman Saeed

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 :-).
Home   |   Site Map   |   Resume   |   Projects   |   Blog   |   Downloads   |   Links   |   Contact