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

Thursday, September 06, 2018

Java EE Adoption Story from Hamed Hatami

One of the most important things to continue to do for Java EE/Jakarta EE is highlight successful adoption stories at a regular cadence. The community has been doing just that for a long time. A number of these stories are curated here. In this vein, Hamed Hatami graciously agreed to share his Java EE adoption story. Hamed is a very experienced early adopter of Java EE that has developed a number of mission critical enterprise applications in Iran and now Sweden.

Can you kindly introduce yourself?
My name is Hamed Hatami and I graduated in Software Engineering from the Azad University of Iran in 2000. I started to work from the last year of my university with various programming languages and frameworks. I have worked for many well-known organizations all around Iran like the Informatics Services Corporation, the Social Security Organization and many others. I have had a lot of responsibilities such as a Software Developer, Software Designer, Technical Team Leader, Technical Consultant and Software Architect.

I have known the Java programming language since 2000 and I fell in love with it right away.

I was the technical leader of many national projects developed with Java EE such as the RTGS–ACH–Chakavak (check management system) for the Central Bank of Iran.

I have a lot of hands-on experience with Java EE technologies like JSF, CDI, PrimeFaces, RichFaces, EJB 3, JPA, Hibernate, EclipseLink, JDBC, JAX-RS, JAX-WS, JAX-B, JSON-P, JMS, ActiveMQ, HornetQ, WebSphere MQ, JBoss EAP, WildFly, GlassFish, MicroProfile and WildFly Swarm.

I am living in Sweden now to learn more in an international environment. Currently, I am working for Cyber Design Nordics as Senior System Architect and I also have another role in Ericsson Corporation as a Contractor.

Can you describe the applications that use Java EE? What does your company do?
Most companies that I worked for are in the Banking and Insurance domains. There are many technical challenges in developing systems for such companies because of the large number of concurrent users and the large volume of data. For instance ACH had to process more than 80 million transactions per day. The Real-Time Gross Settlement (RTGS), Automated Clearing House (ACH) and Check Management System (CMS) for the Central Bank of Iran were developed on Java EE 6 technologies.

Since I came to Sweden, I have been working for Cyber Design Nordics and I have designed and developed two enterprise systems based on Java EE 7 for one of the most famous companies here. Nowadays I am working for Ericsson as a Contractor with the Java EE stack.

Besides these, I have produced a few products myself with Java EE 6 and Java EE 7 like Magnolia Bus, Magnolia ATM Monitoring, Magnolia Dynamic Report Designer and Magnolia Central Authentication and Authorization.

Why did you choose Java EE?
As a matter of fact, I have been a big fan of Java EE for a long time.

I think I was one of the first people in Iran that developed many web applications based on Java EE 5 and JBoss Seam which was a rival for Spring IoC in those days. As a result I had good knowledge of CDI and its advantages from the very first release.

I believe in the Java Community Process (JCP) and the open collaboration of many companies like IBM, Red Hat and so on.

As you know, one of the most important things in software development is Rapid Application Development (RAD) and I think Java EE covers it well. With Java EE each block of your software architecture fits perfectly together.

Each Java EE Application Server has many services included like the Servlet container, the EJB container, the JMS container, transaction management, security modules, Administration Console for monitoring and tracking, etc.

Most high profile projects in enterprises with a large number of concurrent users and large volumes of data need very good software infrastructure and very good architecture to meet non-functional requirements. I think the Java EE ecosystem is designed to handle non-functional requirements like fault-tolerance, fail-over, reliability, scalability, high-availability, security, interoperability, stability and maintainability in the best way possible out of the box.

Because I have had many good experiences with different enterprise projects using Java EE 5, Java EE 6 and Java EE 7, it has become a default choice for me.

How do the applications use Java EE?
As I mentioned before, most of my projects are designed and developed based on Java EE from scratch. In the presentation layer, we usually use JSF with a combination of PrimeFaces, RichFaces, JQuery, ZK and Vaadin with CDI. In the business logic layer, we usually use EJB 3. In the data layer, we usually use JPA/Hibernate.

More recently I have tried to use other platforms such as Dropwizard and Vert.x in some cases.

What was your general experience with Java EE? Would you choose it again?
I have had very good general experience with Java EE such as the many national projects that I mentioned, so I will use it again with new brand features in Java/Jakarta EE 8 and new innovative platforms like WildFly Swarm, MicroProfile and Payara Micro.

How can people contact you if they have questions?
I am always available via email and LinkedIn.

Monday, August 13, 2018

Does the Spirit of JavaOne Live on Inside Oracle Code One?

In this entry I want to share some high level observations with regards to the renaming of JavaOne to Oracle Code One, mention my accepted sessions at Oracle Code One and highlight important Java EE content at Oracle Code One.

Overall Observations
Some of you may already be aware Oracle has decided to rename JavaOne to Oracle Code One. Like many people in the community and for a number of reasons when I came to know of this I must admit I expected the worst with regards to Java EE content specifically and Java content generally. Nonetheless, I am not one to base judgements on sentiments alone but wanted to see in terms of concrete numbers how the renaming played out. An important data point in this regard is the makeup of the content compared to the previous few years of JavaOne. Another important bellwether is the number and quality of submissions (more on that a bit later). I am relieved to say the worst did not come to pass - at least for this year. I'll explain why.

Overall the size of the conference in terms of content has remained the same or grown slightly. There is no question the number of Java related sessions has declined, but the decline is modest. Indeed there was a similar modest decline last year when Oracle introduced the "Oracle Code" track at JavaOne - short of an outright rename of the conference. It seems JavaFX and NetBeans has experienced the sharpest decline of content. There is also no denying a prominent presence for various Oracle centric content in Oracle Code One such as Oracle Cloud, Oracle JET, GraalVM, Fn Project, Oracle DB/MySQL and so on. In fairness, Sun did some of this too in its heyday albeit in a measured way with SPARC/Solaris, MySQL, ZFS, etc content at JavaOne. There are certainly major vendor conferences that seem to be entirely comfortable with throwing all semblance of impartiality out the window. I honestly don't think that is true of Oracle Code One just yet.

Indeed Java EE content is certainly a bright spot. Despite a decline in overall Java content, the amount of Java EE content has remained basically the same. For context, Java EE generally occupies 10-15% of the content or about 50-60 sessions. I'll describe the highlights of the Java EE content in a moment.

The most important point however is this - renaming or not Oracle Code One remains the top destination for both Java and Java EE content. And I say this as someone that firmly believes Java is strong enough to have it's own distinct conference and I loved the fact no other conference in the world came even close to matching JavaOne's Java content in terms of quality or quantity. Despite the decrease, the Java and Java EE content at Oracle Code One still outstrips the closest contender Devoxx Belgium by a respectable margin. While it has been great to see the EclipseCons add quite a bit of Java EE content this year, they do still lag behind the Java EE track at Oracle Code One. It is important to note though that if the current trajectory remains EclipseCon Europe will be the second most important destination for Java EE content, perhaps outstripping Devoxx Belgium. It is also the case that if a further decline in Java content remains a theme for Oracle Code One conferences like Devoxx Belgium and EclipseCon will be in a position to legitimately become the de-facto premier destination for Java and Java EE developers. I am, though, rooting for Oracle Code One. I would hate for the rich heritage of JavaOne fade away entirely. I would rather see JavaOne live on in spirit inside Oracle Code One.

My Sessions
I am happy to say I have four accepted sessions total at JavaOne. Similar to the amount of Java EE content, that is about the same historically for me in terms of accepted sessions. Here are the sessions:

What Is CQRS+Event Sourcing and Why Should Java Developers Care?
In this session I am explaining the architectural patterns of CQRS and Event Sourcing. I'll also be showing through code why Axon is a great way of implementing these patterns in a Java application. Lastly, I will be touching upon why these proven patterns are important for microservices. By then, I hope to mention official Axon support for CDI that I am currently incubating for a few more days on my personal GitHub repository. Although I will be doing some tweaking, the current slide deck for this talk is here.

Eclipse MicroProfile: What’s Next?
This is an evening birds-of-a-feather session primary led by Ken Finnigan of Red Hat and Emily Jiang of IBM. If you want to get the inside story on MicroProfile and Jakarta EE or want to get heard, I seriously suggest you attend this session. I doubt we will have many slides, but we should be discussing issues and ideas that really matter as long as the right audience makes the time to show up.

From Monoliths to Pragmatic Microservices with Java EE
In this lab we will be discussing the fundamental value proposition of microservices and what the Java EE ecosystem offers today in terms of developing microservices. We will start with a Java EE monolith, break it up using just vanilla Java EE thin wars, then apply fat-jars/hollow uber jars/Docker and finally apply some MicroProfile features. I will very briefly talk about where something like Axon fits in the overall picture too. I am honored to co-present the lab with Ondro Mihalyi and Ivar Grimstad. There is quite a bit of tweaking to do, but the current rendition of the slides are here. The current lab materials are here.

Effective Docker and Kubernetes for Java EE Developers
In this session we will be talking about various considerations for running Java EE applications on Docker and Kubernetes such as: whether to use thin WARs, fat JARs, or hollow uber-JARs to effectively work with Docker repositories, layering, and caching; whether to deploy applications within images, through exposed admin ports or as autodeployed mounted external volumes; how Docker clusters, networking, and Kubernetes deployments align with application server administration, clustering, autodiscovery, and load-balancing; how the CI/CD pipeline of your application can be adapted to Docker and Kubernetes; and so on. This is a net new talk being developed with kind help from my co-presenters Ahmad Gohar and Hillmer Chona.

Java EE Content
Mentioning all fifty some Java EE sessions is probably unnecessary and unproductive. I certainly would encourage you to explore the content catalog yourself, even if you don't plan to come to JavaOne. In general the sessions can be put into two categories - API talks mostly focusing on the Java EE technology itself and more how-to style sessions that focus on how to apply Java EE technologies. I've highlighted sessions in both categories that I think are worth specifically mentioning. I would say there is a healthy mix of vendors and community as well as expected names and newcomers. I am particularly encouraged to see IBM, Red Hat, Payara, etc talking about MicroProfile and Jakarta EE, the WebLogic team talking about Java EE and Oracle staff talking about the new Java EE based Helidon project. I would say you should not miss these sessions.

Java EE Technologies
Applied Java EE
Closing Thoughts
With regards to the transition from JavaOne to Oracle Code One, I think a fair sentiment is "so far so good". Beyond the content we will have to see how the rest of the conference goes in terms of venue, execution, vibe, community and most importantly attendance. I certainly will try to do whatever I can to support Oracle Code One. I hope you will consider attending, especially if you consider Java EE important.

While the content is definitely good, there is room for improvement, there is something we can all help move forward and that is where I would actually like to end this entry. From somewhat an insider standpoint, there are signs it was not easy for the organizers to select quality Java EE content. Tell-tale signs are repetitive material and certain speakers with larger number of sessions (and yes, I am including my own sessions in that observation). I suspect the quality and number of Java EE submissions was lower than it really should have been in JavaOne/Oracle Code One terms. If this was indeed the case, it is deeply disappointing because we should be fully standing behind the conference at least for now. One simple way to do this is adopt the ideas and content I have tried to share a few times already. In particular I think Oracle Code One could have used more content around various aspects of Java EE 8 as well as specific MicroProfile API/specification talks. This is something both vendors and community folks can do something about - and certainly beyond just Oracle Code One. If there is something I can do to help in this regard, I will be delighted to do so.

Saturday, April 28, 2018

Using Java EE 7 to Develop Medical Applications in the Czech Republic

One of the most important things to continue to do for Java EE/Jakarta EE is highlight successful adoption stories at a regular cadence. The community has been doing just that for a long time. A number of these stories are curated here. In this vein, Vladimir Herman graciously agreed to share his Java EE adoption story. Vladimir is a young developer in the Czech Republic working on medical applications. He has experience with both Spring and Java EE applications. Thanks very much Pavel Pscheidl for helping facilitate the sharing of this Java EE adoption story.

Can you kindly introduce yourself?
My name is Vladimir Herman and I am a Java developer in one of the largest Czech software companies. I started working with Java professionally in 2013, when I was still a student at the University of Hradec Kralove. I was employed as a junior Java developer in the internal IT department of an insurance company. That’s why I look at my career in two separate stages - during and after my studies. I have learned a lot from academic life as well as from practical work experience.

Can you describe the applications that use Java EE?
In my previous job, we developed web applications in Java that were based on the Spring framework. In my current job, we are extensively using Java EE 7. We develop medical applications for foreign and domestic customers, such as ministries, hospitals or polyclinics.

The applications are mainly used by trained employees of these institutions. That means they are demanding customers who precisely know the problems related to the application domain. This greatly increases demands on the services provided by our system.

Why did you choose Java EE?
The first contact with programming was completely different for me. At lower grades of my education I encountered procedural programming and languages such as assembler and C. I got familiar with the object-oriented paradigm through Java SE/Java EE at the university and I immediately thought it was the right choice for me.

One of the major benefits of Java EE is its comprehensive portfolio of technologies and APIs. Java EE is a mature technology, it has a diverse ecosystem as well as a very active community. It is also beneficial that you can extend the platform with various frameworks when needed.

The seamless integration of the individual parts of Java EE is invaluable. Integration is not always trivial and you have a very powerful tool in your hands once you grasp this concept.

We must not forget the benefits of the JVM itself. It is great to have a portable and platform independent runtime, considering the diversity of our customers.

How do the applications use Java EE?
During my relatively short professional career, I was able to experience the development of Spring framework as well as Java EE technology stack applications.

The applications on which I work mostly follow a layered MVC architecture. Java EE technologies are used in all layers of the application. The main technologies in use are JPA, CDI, EJB, JAX-WS and JSF, but of course there are more. The vast majority of our applications are designed to be monolithic robust units that are self-contained. Individual applications are able to communicate with their neighbors using SOAP when needed, but we also run applications that use JMS. The resulting system can be thought of as composed of multiple large modules, but they are certainly not microservices quite yet.

I started working on an application based on J2EE 1.4 about a year ago. It is a key application for a few important customers and it has been in maintenance mode for many years. Developers were hesitant to make larger changes that could endanger existing functionality or would not be backward compatible. A recent breakthrough occurred when the application was bought by another customer. The application now needs to be rejuvenated as a result. Some of the technologies have become obsolete enough to be replaced outright and others were upgraded to the current version. One of the major changes was switching to Java EE 7 and replacing JSP with Facelets/JSF. Another crucial step was the introduction of DI through CDI. All changes were made with an emphasis on easier maintenance in the future.

What was your general experience with Java EE? Would you choose it again?
I gain experience with Java EE every day. Java SE 9 was released not too long ago. Java EE 8 brings changes like asynchronous events for CDI, HTTP/2 support in Servlet 4 and so much more. I am just in the constant process of learning, reading documentation and testing my knowledge in the real world.

I think there is a bright future for Java EE and I would certainly use it again.

I have also noticed the arrival of Spring Boot. It adds another layer of abstraction for applications based on the Spring framework but it is still a step in a good direction in my opinion.

How can people contact you if they have questions?
The best way to contact me is by email at hermicz at gmail dot com.

Saturday, March 03, 2018

Java EE @ DevNexus 2018

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.

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