DZone/Java EE Guardians Survey Results: Microservices

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 4, Java SE 8 alignment as well as Java EE security.

Besides asking about relatively straightforward Java EE 8 features, we asked a number of more complex, foundational questions towards the end of the survey. In the prior entry, in this entry and a subsequent few others I am going to take a closer look at some of these questions. I'll then return back to looking at the more mundane Java EE 8 feature specific questions. It will be clear in a few weeks why this change of order is important at the moment.

The Question
In the prior entry I looked at one of the most fundamental questions we asked - the complex relationship between standards and innovation. If you have not yet read the entry, I think it is a good idea to take a look as vital context to the current entry. In this entry I'll explore the question we asked about standardizing microservices specific features in Java EE. This is a particularly important question that deserves a very in-depth look. It is certainly a question Oracle, vendors, the community and Java EE's usual antagonists are paying a lot of attention to so getting this right for everyone is crucial.

Here is how we phrased the question:

"Microservices is a relatively vague term. It can be interpreted to mean decomposing a larger logical application into smaller independently deployable subsystems.

There are frameworks that claim to specialize in microservices and include features such as custom configured, self-contained executable jars (also known as “fat jars” or “uber jars”), metrics, discovery, circuit breakers and bulkheads. Java EE currently does not include such features but it may make sense to add them. It should be noted however that Java EE centric tools such as WildFly Swarm, Payara Micro, WebSphere Liberty and KumuluzEE do offer such features.

Keep in mind, there are some industry thinkers like Martin Fowler that have expressed doubt whether microservices make sense for most applications. Some other folks such as Adam Bien believe Java EE is already well suited to building practical microservices.

How should Java EE approach microservices?".

The Results
The following graphic shows how the community responded. It's not realistic to think there would be a simple answer to a pretty complex question, but there are clear patterns. A sizable minority of 44% respondents want Java EE to standardize microservices specific features. The majority 56% however want to wait to standardize or do not want to standardize any further microservices features in Java EE. 27% believe Java EE already has sufficient support for building practical microservices applications. Though not entirely, my personal views most closely resemble this group. I'll explain myself a bit more later in this writeup. I've also explained my views in this screencast. A further 25% believe Java EE should wait to standardize anything more until microservices are better adopted in the practical enterprise. 4% believe microservices is just hype and should simply be ignored.

To put some of this into context, the level of support for standardizing microservices specific features is much weaker than standardizing features such as HTTP/2, more JSON, Java SE 8 alignment, Java EE security and dynamic configuration (some of these items enjoy near 90% support). Indeed the level of support was higher for the Java EE MVC API that has now been decoupled from Java EE and is being led by the community instead of Oracle. The level of support for microservices is essentially in line with standardizing features such as NoSQL and reactive programming.

Digging a little deeper into the data, there is a high degree of correlation between folks that support more microservices features in Java EE right away and folks that equate Java EE to a product instead of an open standard or don't mind standardizing concepts that would very likely be considered Hype-Driven Development (HDD) by most ordinary developers in the blue collar enterprise (the very readable, extremely unassuming and sensible HDD write-up tellingly includes microservices, NoSQL and reactive programming as prominent examples; if you haven't done so already, I highly recommend reading the linked article). In effect these folks would not agree with the currently fairly conservative approach to Java EE standardization.

A majority of the people that put in comments essentially had a pretty ambivalent view of adding more microservices features to Java EE right now. Perhaps the folks that have decided to advocate microservices for a few years now without many reservations should pay heed to folks like these? Here is a representative sample of comments:

• "I believe microservices hype will eventually die down".
• "The hype is already fading. Wait a little and it will be replaced with the 'next big thing'".
• "Stop the nonsense with uber jars and let a Java EE server have configurations that let the application define what modules are needed".
• "The success of Java EE centric tools like WildFly Swarm will dictate the need, or lack thereof, for standardization".
• "Java EE is well-suited to providing microservices. I am not at all convinced that WildFly Swarm's approach to service discovery, for example, is something that should be standardized - it makes sense in some use cases, but not others".
• "I would have picked standardizing fat jars from the first point. The others are just design patterns or good practices".
• "99% of applications won't need this. Only very large internet scale companies need microservices. Java EE is mostly used for corporate internal web applications (at least in my experience)".
• "Although I agree that Java EE already provides the minimum tools to create microservices I think it would be important to make some de-facto guidelines and tools. In particular I think it would be important to have a well-defined standard for self-contained executable jars".
• "Let the container developers (JBoss, GlassFish, etc) work on this for another couple of years and let it evolve".
• "WildFly Swarm should be the example to follow, by letting the 'just enough application server' idea to settle".
• "I think the only big challenge is developing a how-to that integrates Java EE with a handful of other technologies to create a microservices architecture which is good enough for everyone else who's not Netflix".
• "Much of microservices is hype and is already experiencing some backlash".
• "For me microservices is an architecture. I think that Java EE as a platform should not be seen as a framework that follows some specific architecture principles".
• "Let's wait for MicroProfile and build something upon it".
• "JBoss like application servers already support modularity, which in many ways make servers lean. A similar kind of standards based approach will help anyone build microservices with their own feature sets enabled".
• "Microservices are excellent in some cases, but most enterprise systems don't really need microservices. Combine cloud and application server in the right way and we have microservices in the cloud".
• "We should just tell developers/architects (or maybe just management) that we're not all Netflix".
• "I agree with Martin Fowler that microservices are not already proven and also that they are not required for many applications".
• "I agree with Adam Bien. Supposedly 'lightweight' solutions tend to become heavy over time. I do think it is great to have options so having WildFly Swarm, Payara Micro, etc is a good thing".
• "Microservices are hype, but can not be neglected. The main driver is actually to get more control of deployment and of configuration for developers. Java should provide mechanisms for that, which would be helpful regardless of whether microservices survives".
• "I would argue that Java EE fits nicely with microservices as it is today. It is more an architecture choice of style if you find monoliths or microservices a better fit for you".
• "I agree with Adam Bien that Java EE is already well suited and also with Fowler that microservices may not make sense to most applications".
• "Application servers with minimum required modules makes sense, but standards are probably not required".
• "None of the projects I've worked on would have benefited from being decomposed into microservices".
• "Java EE already provides the tools for building microservices. I think it should only create new profiles for microservices which provide the principal JSRs".
• "Microservices are an architectural pattern, there is no need to standardize it in Java EE".
• "Java EE should not start to standardize all named features at once but maybe start with uber jars".
• "Time will bring more understanding and consensus as to what a standard should look like".
• "Java EE is already great for microservices development. Trust Adam Bien :-)".

More Microservices Data Points
I don't think there is any denying the fact that Oracle's own Java EE 8/9 survey was heavily (perhaps even solely) focused on microservices including the way the questions were phrased as well as the questions themselves (you should judge for yourself: the survey text and results are here). One would expect that support for microservices would be much higher in those results than our survey as a result. I don't think that is what actually happened. Most of the very microservice specific features such as service health, circuit breakers and modularity/fat-jars ranked below average (that is below 10 amongst 21 items surveyed, in order of importance). Indeed most of the items that ranked above a 4 were pretty mundane items like HTTP/2, REST, JSON, security and configuration. For context, 1 indicated "Not Important" while 5 indicated "Very Important". Items such a reactive programming, eventual consistency and NoSQL all ranked between 3.5 and 4.

Beyond our and Oracle's surveys, there is another excellence source of reliable public data we can look at on microservices. The 2016 RebelLabs survey understandably started including questions on microservices. The graphic below shows the results of the survey. Because of the complexity of the question patterns are harder to see but I think it's safe to say the results are mixed. After a few years of fever pitch hype, only 34% say they have moved to microservices. Of that percentage, only 40% said moving to microservices has had a benefit for them. In terms of total percentages, that's only 15% of developers realizing a practical benefit from microservices. There are also a troubling data points - 18% of "early" adopters reporting microservices have made life harder for them. Most - 42% - have not seen any real benefit to adopting microservices. Of non-adopters, 32% already say microservices are not for them while another 56% are basically still on the fence.

I think this is hardly the results to thrill the veritable chorus of vendors and "industry thought leaders" unabashedly cheerleading microservices for a while now.

Hype and Reality
The fact that ordinary developers still continue to have mixed feelings about microservices is not a surprise either to me or most folks I know personally in the community. There has been and continues to be a steady stream of people duly warning against the hype. One has to give due credit to Martin Fowler. He was one of the earliest prominent folks to write about microservices but he is also one of the earliest folks to warn about the hype. I don't think you can get any clearer about what is going on than saying "enough to get everyone's over-hyped-bulls*#% detector up and flashing" or "the majority of software systems should be built as a single monolithic application". There have even been some pretty brave folks on the vendor side on the equation. Ruby on Rails creator David Heinemeier Hansson wrote an excellent blog entry titled "The Majestic Monolith" that is well worth reading for all server-side developers. My friend and fellow Java EE enthusiast Adam Bien has even gone as far as to making a fairly bold prediction of a backlash against microservices and uber jars as soon as this year. There is plenty more around once you begin looking including some humorous but pretty insightful memes from ordinary folks.

It is safe to say like these folks, I don't mind being called a microservices skeptic. While I'm sure it doesn't help our egos much, I don't think most companies have the same problems as Netflix, Amazon or Google (and yes, that includes most Fortune 500s). For the vast majority of applications out there, microservices seriously violate the YAGNI principle - the associated costs and complexities are just not worth it and never will be. My general rule of thumb for considering microservices for most real world projects is a team size of about 7-10 active developers.

For projects that can actually benefit from microservices, the "micro" part of microservices still violates the YAGNI principle. Indeed what makes sense is breaking these systems down into pretty sizable sub-systems with distinct sets of business users. An example would be a larger insurance system that is broken down into point-of-sale, data capture, underwriting, policy management, payments, customer service, reporting, archival, etc sub-systems. The reality is that many of us have been successfully developing both these types of "microservices" applications in addition to monolithic applications with vanilla Java EE for a long time now.

This pragmatic approach is far away from the CORBA-like remote objects most microservices proponents seem to have an infatuation with where you would see dozens if not hundreds of distributed remote services comprising an application like account service, product service, user service or order service. There are only a tiny handful of companies that actually benefit from this level of granularity. These are the types of applications that really need the features that are offered by products like WildFly Swarm or KumuluzEE beyond what vanilla Java EE already offers. I've explained all of this in a fair amount of detail beyond what I have the space to say here in the screencast I referenced earlier in this entry.

What Should be Done in Java EE?
Whatever the right thing to do in Java EE is, Java EE vendors should not let microservices hype pass them by. They should absolutely make sure their Java EE centric products are microservices "buzzword compliant". Part of the issue is that it will take a while for pseudo-technical people in IT decision making roles that nonetheless hold CIO, CTO, architect and development manager titles (some of us lovingly call these people "PowerPoint Architects"; I'm sure you know the type) to be able to separate the hype vs. reality of microservices. Some may only learn the hard way by experiencing project failures, cost overruns and maintenance headaches themselves. We have to be honest with the fact that Java EE is not completely immune from the need for buzzword compliance either. That said if Java EE capitulates every time the hype of the day came along, it would quickly lose it's well-recognized core value proposition as a stable, backwards-compatible open standard that serves as a buffer against hype and minimalist core for broad ecosystem innovation (indeed this is precisely what went wrong in the J2EE era).

I really don't think most of the features that Oracle is proposing for Java EE 9 really should be standardized yet. This includes things like dynamic discovery, metrics, circuit breakers, client-side load-balancing, eventual consistency and so on. Just as is the case with WildFly Swarm and KumuluzEE, at this stage vendors should be actively innovating with and building on top of Java EE for these sorts of features. Collaboration on microservices features through open source initiatives like MicroProfile is also an extremely good thing. This approach allows for the usability and applicability of these features to be much better understood and allows ample space for the ecosystem to fully innovate before any standardization takes place. Maintaining a product-first approach also means these features get to developers faster, as they need to meet (real or imagined) needs. Mutual collaboration through MicroProfile also allows for rapid standardization later when the time is right. On the other hand, if the microservices ambivalence now in conference talks like "Microservices for Mere Mortals" and "The Dark Side of Microservices" turns into a full-scale grassroots backlash down the road, these features need never be standardized in Java EE. I'd say the biggest problem now is that Oracle is not part of MicroProfile and does not have an open, collaborative microservices product plan outside of what they said they wish to do in Java EE 9.

None of the above means there aren't features that shouldn't be moved forward in the core open standard. There are plenty of more straightforward Java EE features that I think would be welcomed well by the community:

• Features like dynamic configuration and OAuth/OpenID support have been relatively well-awaited, are reasonably well-understood would be useful for projects whether they are using microservices or not.  Oracle initially considered these features for Java EE 8 but then appears to have deferred these features to Java EE 9 in order to deliver Java EE 8 faster (a welcome move).
• Considerations to fully modularize the platform has been around since the Java EE 6 timeframe. The big practical hurdle to doing this was the fact that Java did not have a built-in module system. I have to be honest in that I think modularity is a bit of a Red Herring overused in the usual anti-Java EE rhetoric. I'll write more about this in a slightly different context in the next few weeks but I don't think modularizing Java EE is a practical issue when the average Web Profile implementation is 35-50 MB and the average full profile modern Java EE application server is 120-150 MB. Let's remember that the commodity disk space these days is approaching the terabyte range and an average network speed of over 10 mpbs is really not that uncommon anymore (I do have to admit there continue to remain real disk size offenders such as WebLogic at 800 MB - 1.5 GB). That all said, Java SE 9 modularity makes modularizing Java EE along the lines of it's already separated constituent JSRs a real possibility and something that would be welcomed by many. This feature does have a real use case in very resource constrained embedded systems/IoT use cases. Indeed much of this has been possible in modular application servers like GlassFish since the Java EE 6 time frame.
• To go along with modularity, it would be useful to have additional profiles in Java EE. For example a very minimal Servlet-only "Core Profile" and a "Microservices Profile" targeting a simple, non-persistent but JSON-capable REST endpoint certainly makes sense. This is very similar to what was done with Java SE 8 Compact Profiles.
• Similar to modularity, I don't think fat-jars are as cut-and-dry as most people seem to think. In fact I think Adam Bien might be right that fat jars can prove to be an actual anti-pattern with Docker compared to Java EE thin war files with time. That said, embeddable containers have been advocated for a long time in the Java EE expert group. I do think standardizing fat jars would be welcome by many in the community. Again, most application servers other than WebLogic already have this capability now. They do have a legitimate use case when working with bare metal JVM based PaaS environments that make a separate server installation difficult.

Going forward, the positions in this section is what I plan to personally advocate in the Java EE expert group. That said, there is always ample room for learning more in our ever volatile industry and perhaps my views will evolve over time as things continue to move forward.

I do hope this post serves as food for thought in the complex topic of Java EE and microservices. Please do stay tuned as I further look at topics in the survey. In addition to my write-up, I would encourage you to look at the survey results yourself and get involved in Java EE. You can certainly do so by becoming a part of the Java EE Guardians.

JAX-RS 2.1 Early Draft Review Starts Now!

JAX-RS 2.1 just posted it's first early draft review. Because of the now accelerated Java EE 8 schedule, the rest of the steps towards finalization of the specification is going to happen very quickly.

As the release versioning indicates, this is a relatively minor JAX-RS release. However there are a few very important changes in the release both for JAX-RS users and server-side Java developers at large. Besides smaller grain items, these are the major changes in JAX-RS 2.1:

• The introduction of reactive capabilities in the JAX-RS client API. This is largely based on the Java SE 8 CompletableFuture API but the way the changes are designed most JAX-RS providers will also provide native support for RxJava. In essence this change allows for far more robust asynchronous, non-blocking, functional and composable REST endpoint invocations via the JAX-RS client API.
• The addition of HTML 5 Server-Sent Events (SSE) support both on the JAX-RS server and client side API. Jersey had long added such support in it's proprietary API in the Java EE 7 timeframe. This change further improves HTML 5 alignment for JAX-RS and Java EE.
• Although it is not included in the early draft review, JAX-RS 2.1 is set to add non-blocking IO (NIO) support. Unlike the Servlet API which supports both asynchrony and NIO, JAX-RS so far only added asynchronous support as of JAX-RS 2. The JAX-RS 2.1 expert group is now currently actively working on the changes for NIO support. It should make it into the next specification draft.

At the moment the best way to learn more about what is in JAX-RS 2.1 is looking at the specification draft itself. Page 81 of the document has a nice log of changes since JAX-RS 2. Pages 36-38 describe reactive client support. SSE support is described in pages 57-60.

While the specification is going to finalize soon, there are still plenty of reasons to get involved. Here are the many ways you can still engage (most of this comes directly from the Adopt-a-JSR page I drafted while still at Oracle):

• You can still join the specification itself as an expert or a contributor. You can do that via the JCP page for the specification.
• You can have your JUG officially support the standard through Adopt-a-JSR.
• You can simply join the discussion without any ceremony by subscribing to the JAX-RS specification user alias.
• You can share ideas and feedback, possibly by entering issues in the public issue tracker.
• You can read the draft specification now.
• You can try out the reference implementation now.
• You can write or speak about the API now.
• You can encourage others to participate.

The next step is up to you. You can be a part of the effort to keep moving forward the popular JAX-RS specification. If you have any questions I am happy to try to help - just drop me a note any time.

Vaadin Community Survey Confirms Java EE Used More Broadly Than Alternatives

For those unaware, Vaadin is a popular GWT based RIA Java web framework. You may also be surprised that the Vaadin community is 150,000+ strong. To better understand this community the Vaadin folks fairly recently ran a survey. One of the things the Vaadin folks wanted to know is how often Java EE is used compared to alternatives. The results of the survey certainly look encouraging for Java EE, particularly given the seemingly perpetual nay-saying around Java and Java EE in predicable corners of our ever "colorful" industry.

The results for Java EE usage are shown in the graphic below. The most number of respondents - 41% - identified themselves as Java EE users. I think this is truly remarkable for a mature open standard like Java EE with a number of non-standard product vendors aggressively positioning themselves as competitors to Java EE for many years now. The relatively sizable 27% of respondents that indicated "other" is also quite interesting. It is possible these folks simply use Vaadin as their primary server-side toolset.

It is important to note though that the sample size is significant but small - 250+. That said, the survey is very reliable in one very important way. The survey was not anonymous/online but was from known and clearly identifiable members of the Vaadin community. This certainly helps reduce but not completely eliminate possible self-selection bias in an online survey. It's also remarkable how similar these results are to other larger surveys from reliable, neutral sources (the DZone survey results are in the graphic below). The survey illuminates some other interesting but somewhat predictable findings - I would encourage you to look at the entire survey results.

While the Java EE platform has long included JSF as it's primary web framework, I personally know of a good number of folks that actually use Vaadin with Java EE. Indeed I'd say it is one of the best if not the best RIA web framework out there (although I must admit I am a fan of PrimeFaces as an alternative to mucking around with JavaScript). It is really nice that Vaadin has long included strong support for Java EE.

While all of this is good news, the Java EE community can ill afford to rest on it's laurels. The community has hard work ahead of it as always to continue to serve developers of all stripes. On behalf of the Java EE Guardian community it is only correct to thank everyone that indicate their support for Java EE in such surveys. Our volunteer driven work is intended to benefit you first and foremost - it is good to see that intent does not get lost in the muddle.

Java EE Security Early Draft Review Starts Now!

The Java EE Security API just posted it's first early draft review. Because of the now accelerated Java EE 8 schedule, the rest of the steps towards finalization of the specification is going to happen very quickly.

Java EE security is one of the most anticipated changes in Java EE 8. This is the case particularly because security is one of the last areas left to be revamped in the way most other Java EE APIs such as EJB 3 have been changed radically. As a result Java EE security is very highly dependent on things like vendor-specific GUI console wizards, vendor-specific configuration or command-line administrative tools. Pluggability, extensibility and customization is also currently challenging when the security features that already come with the application server are not sufficient. This is the main reason for the existence of third-party security frameworks in server-side Java like Shiro and Keycloak. The Java EE Security API aims to solve these important issues and promote both simplicity as well as portability, particularly on the cloud.

The best way to learn more about what is in the specification is looking at the specification draft itself. Another great way to get yourself familiarized is looking at the slide deck from key expert group member and my friend Rudy De Busscher (please click here if you can't see the embedded deck).

What is tackled in the Java EE Security API (Java EE 8) from Rudy De Busscher

While the specification is going to finalize soon, there are still plenty of reasons to get involved. Indeed this has been one of the most heavily community driven Java EE 8 specifications. Here are the many ways you can still engage (most of this comes directly from the Adopt-a-JSR page I drafted while still at Oracle):

• You can still join the specification itself as an expert or a contributor. You can do that via the JCP page for the specification.
• You can have your JUG officially support the standard through Adopt-a-JSR.
• You can simply join the discussion without any ceremony by subscribing to the Java EE Security API specification user alias.
• You can share ideas and feedback, possibly by entering issues in the public issue tracker.
• You can read the draft specification now.
• You can try out the reference implementation now.
• You can write or speak about the API now.
• You can encourage others to participate.

The next step is up to you. You can be a part of the effort to simplify and improve security in server-side Java. If you have any questions I am happy to try to help - just drop me a note any time.

DZone/Java EE Guardians Survey Results: Standards and Innovation

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 4, Java SE 8 alignment as well as Java EE security.

Besides simply asking about Java EE 8 features, we asked a number of fundamental questions towards the end of the survey that go to the core of Java EE itself. In this entry and a subsequent few others I am going to take a closer look at some of these questions. I'll then return back to looking at the more mundane Java EE 8 feature specific questions. It will be clear in a few weeks why this change of order is important at the moment.

The Question
One of the most important fundamental questions we asked is around the complex relationship between standards and innovation. This question and its responses deserve a particularly in-depth look.

Here is how we phrased the question:

"Innovation and standardization is a tricky balance. Standards are pervasive, heavily relied upon and often strongly backwards compatible. For these reasons standards generally only include clearly proven ideas and avoid unproven ones. One can argue EJB 2 Entity Beans were an unproven innovation that was standardized too quickly. The Java EE ecosystem can always innovate ideas that are later standardized when proven.

That being said, standardization is an engineering activity and inevitably includes some level of innovation. It may also be the case that Java EE is different in terms of an open standard as it heavily competes with non-standard technologies.

How should Java EE approach innovation?".

The Results
The following graphic shows how the community responded. It's not realistic to think there would be a simple answer to a pretty complex question, but there are clear patterns. The most number of respondents (43%) essentially agreed with long-standing Java EE expert group consensus. Specifically this means taking a relatively conservative, organic approach to standardization. A further 14% favored a very conservative approach to standardization, forming a significant but not overwhelming majority. About 21% respondents had essentially the opposite view, equating Java EE with non-standard products. For context, this would basically mean standardizing features in products that are rarely used even by their own users. A further 23% favored a slightly more conservative approach that is still OK with standardizing ideas that are yet unproven. For context, these are most concepts that would very likely be considered Hype-Driven Development (HDD) by most ordinary developers in the blue collar enterprise (the very readable, extremely unassuming and sensible HDD write-up tellingly includes microservices and reactive programming as prominent examples; if you haven't done so already, I highly recommend reading the linked article).

People that put in comments for the most part supported the existing Java EE approach to standardization. Here is a representative sample:

• "Focus on reliability and long-term planning, Java is the backbone of many enterprises"
• "I do not believe that Java EE should introduce any wildly new concepts or approaches"
• "Stability is way more important than college kids' untested and unproven ideas"
• "Considering the purpose of Java EE in the first place, only those innovations should be considered that reduce bugs, increase stability, keep backward compatibility and reduce cost"
• "The most valuable thing about Java is that it's backwards compatible, so innovations should be standardized very carefully. Innovations are to be provided by libraries, frameworks, etc"
• "I firmly believe in Java EE as a robust, reliable, base stack upon which to build the rest of your tech stack. As such, I don't really think innovation should be seen much in it's purvey. Let third party libraries, frameworks, and vendor-specific features take charge of innovation. Meanwhile, the Java EE specs should keep making sure to standardize as much of the proven ideas as possible to allow communities to disengage from specific implementations as much as possible"
• "I see standardization as a final step of a lengthy engineering process. Changing a standard after it gets established is always difficult and if it is frequently required, it'll be quite counterproductive"
• "Since standards are there to last at least for a few years, I prefer a more conservative approach"
• "It is important for Java EE to try to limit it's scope only to proven ideas and make them standards. For all other ideas there is always the possibility to evolve as open projects and once they prove they are good Java EE can adopt them"
• "Our industry is full of hype, it is a decease. Java EE should be free from it"
• "Let the industry innovate...then standardize later. Don't discourage the use of non-standard libraries"
• "For me, standardization is a refining activity, which means to take the best approaches and bind them together in a way that makes sense and eases developers' work. Innovation for innovation's sake is not worth the effort since it takes resources away from other areas that need improvement"
• "Java EE should be conservative"
• "Innovations may be provided by vendors, no need to standardize them"
• "One of the selling points for Java EE is the stability and robustness. If we start to introduce the innovation-of-the-day into Java EE, then we will threaten that stability"
• "There can be innovation on top of Java EE. Once they are proven - and if found necessary - they can be included as standards later on"
• "I'm all for new ideas, but if they're going to make it into Java EE, the reason needs to be that people actually need them. Not just because X is the latest buzzword"

Java EE Innovation Approach in Context
To understand the real significance of the current implicitly conservative approach to Java EE standardization, it is important to have some context.

I don't think it surprises ordinary enterprise developers that technology vendors do not behave very responsibly when it comes to hype. Although there are a few brave souls, many do not have the correct incentives to self-regulate responsibly against hype. Even the ones that actually do have some good intentions are often slaves to their own egos, groupthink and isolation from down-to-earth blue collar enterprise development. Indeed grossly exaggerating the real world applicability (and consequent profitability) for startup(ish) ideas has become a such a habitual problem in Silicon Valley in recent years that it has long been hard to find companies that don't do it (if you haven't read the book "Disrupted" I highly recommend you do it soon). Quite frankly typical conference speakers, self-declared "industry analysts/thought leaders/opinion makers" and a certain class of consultants aren't any better at any of this either.

As the Hype-Driven Development writeup author correctly points out, the ultimate safeguard against hype is ethical, responsible, business-value-focused developers that see the wasted effort, inflated costs, ongoing maintenance complexity and outright project failures that constantly chasing hype causes. Open standards, as an insulator between end-users and vendors have an important role to play as well. Indeed the many non-vendor independents in Java EE JSRs that I've had the honor to work alongside for years have long guarded carefully against hype. They understand well that guarding against hype and promoting long-term stability/simplicity is one of the most valuable things open standards can uniquely provide by encouraging direct early participation from real end-users as key stakeholders in Java EE expert groups. It is no coincidence that the worst standardization mistakes in Java occurred in the J2EE era when expert groups were almost exclusively vendor dominated. EJB 2 Entity Beans and an overzealous emphasis on EJB remoting/distributed objects were the key HDD ingredients of their day (indeed there are far too many stark parallels between distributed objects and microservices - it's almost as though our industry is choosing to stubbornly forget the hard-earned lessons of the past :-)).

Often the only real way of getting things right is taking the lessons of past mistakes to heart. I think for many years now that has been true of Java EE. Most of the key changes in Java EE 5, Java EE 6 and Java EE 7 have been about standardizing ideas that have already been reasonably established. This includes standardizing JPA based on Hibernate, TopLink and JDO, standardizing CDI based on Seam, standardizing Bean Validation based on Hibernate Validator and standardizing JSF features based on RichFaces, PrimeFaces, OmniFaces, Seam Faces and DeltaSpike. The great lesson Rails had to teach Java EE is that it is OK to be a highly opinionated framework that wholeheartedly embraces the integrated platform concept and convention-over-configuration. Java EE 5 took those lessons to heart and frankly the Java EE community still enjoys the real benefits of those changes in a way few other communities do even today (and as many of us understood from the start neither Ruby nor Rails "took over the world" but instead found their own comfortable space for success; many of us in the Java EE community view Node.js in the same light today despite the tiresome hype now).

There have of course been some well-vetted organic innovations in Java EE as well. Examples include using annotations as metadata in EJB 3, declarative style service endpoints in JAX-WS, JAX-RS and WebSocket, CDI @Observer, @Stereotype, @Decorator and InjectionPoints as well as EJB 3 @Asynchronous and @Schedule. Some of us find it more than a bit ironic that many of these changes are actually quietly adopted later by frameworks that position themselves as rivals of Java EE but simultaneously claim a veritable monopoly on innovation in server-side Java...

By contrast there has been hype that the Java EE expert group has chosen to bypass, I think for the better. SOA is a fairly clear example. Even at the height of SOA hype, Java EE essentially kept SOA specific features at arm's length, limiting it to the basic ability to publish SOAP endpoints using JAX-WS. Thankfully Java EE never over-reached into the inevitable quagmire of ESBs, enterprise integration frameworks or the WS-* family of specifications. The only small step in this misguided direction ended relatively expeditiously with the pruning of JAXR in Java EE 6.

I know my saying so will not sit well with some of my fellow Java EE expert group members, but another good example is Java EE largely bypassing OSGi hype. It was obvious from the start that the complexity of the OSGi model/runtimes coupled with the complexity/needlessness of trying to modularize most real world applications was bound for failure in the blue collar enterprise (does anyone still even remember Spring Dynamic Modules or SpringSource dm Server?). Java EE ended up making no changes to try to accommodate feverish OSGi hype of the day. What happened was far more pragmatic. With the notable (and unfortunate) exception of WebLogic, Java EE vendors modularized their runtimes instead - performing a very difficult ground-up rewrite few other non-trivial software projects would have likely survived. I think a particularly brave shining examples of this is WebSphere Liberty. IBM could have just stopped at embracing the Web Profile via WebSphere Classic. Instead they chose to simultaneously embrace the Web Profile, a total rewrite and ground-up modularity via WebSphere Liberty.

This complex and nuanced context is why some of us raised an eyebrow when we saw some of Oracle's Java EE 9 ideas. Frankly it is the reason the question on innovation and standardization showed up in the survey at all. Some of the Java EE 9 proposals look more along the lines of the past mistakes made in the name of vendor-driven innovation/time-to-market concerns of the J2EE era than the more measured, community-driven standardization of the Java EE era. Conversely, this is also why most Java EE folks see the critical value in the MicroProfile effort and projects like WildFly Swarm that innovate with Java EE and serve as pipelines for standardization of proven concepts.

Java EE as an Enabler of Innovation
This discussion will not be complete without some understanding of the fact that Java EE does far more than simply passively standardize proven changes. Java EE actually seeks to enable innovation in more fundamental ways than most seem to know or wish to acknowledge.

There is a curious charge out there that Java EE somehow discourages innovation by insisting that developers only use standard APIs and only the platform. At best this is a grossly outdated idea that persists from the J2EE era fueled by ignorance. At worst it is a bit of deliberately designed anti-competitive propaganda.

The reality is that Java EE has long done it's best to promote innovations through plug-ins, extensions and conservative standardization. Every expert group in virtually every Java EE JSR works hard to make sure Java EE APIs have ample extension points that both the community and vendors can use. Some obvious examples include the CDI portable extensions API, CDI interceptors, Servlet filters/listeners, JAX-RS interceptors/filters, JPA unwrap methods, the JSF component model, the WebSocket programmatic API, WebSocket encoders/decoders, Bean Validation custom constraints, JCA connectors and many more. The clearest message of the active encouragement of ecosystem innovation that builds on the platform comes from the very charter of Java EE from years past now:

"It would not be appropriate for the Java EE platform to grow without bound to include all the interesting and useful technologies desired by web and enterprise application developers. Instead, we believe it is desirable to enable more of these technologies to cleanly layer on or plug in to Java EE application servers. By adding more extensibility points and more service provider interfaces, these other technologies can plug in to platform implementations cleanly and efficiently, and be just as easy to use for developers as the facilities that are built into the platform".

These are the capabilities and underlying philosophy that powers projects like Seam, Arquillian, DeltaSpike, PrimeFaces, OmniFaces and so many more. Indeed these capabilities power the very products that aim to position themselves as alternatives to Java EE.

The Java EE platform goes farther than simply provide extensions. It has long been the case that almost every Java EE API is also available outside the platform in a standalone fashion. This is the case despite the fact that these APIs target Java EE in their JSR charter, closely integrate with other Java EE APIs, coordinate heavily with the Java EE expert group both in terms of schedule as well as content and are often directly funded/staffed by product teams that provide commercial implementations of the Java EE platform rather than an individual API. These standalone parts of Java EE can be used basically in any way anyone can imagine. This takes substantive hard work and real investments that even the most aggressive competitors to Java EE can and do routinely take advantage of. A good friend and fellow Java EE expert group member once asked me "why do we do this to ourselves?". The answer is that it is the right thing to do in order to promote innovation and extend the value of Java EE to the ecosystem far beyond the boundaries of just those folks that embrace Java EE as a cohesive platform. The hope of course is that some of the resulting innovation would make it's way back to the platform. There is no other platform, standard or otherwise, that goes to such lengths to empower innovation in a very broad ecosystem. Failing to properly acknowledge these facts does serious disfavors to the very ecosystem that benefits from Java EE.

I do hope this post serves as food for thought in the complex topic of Java EE, standards and innovation. Please do stay tuned as I further look at a few more similarly fundamental topics in the survey. In addition to my write-up, I would encourage you to look at the survey results yourself and get involved in Java EE. You can certainly do so by becoming a part of the Java EE Guardians.

Java EE @ DevNexus 2017

DevNexus 2017 was held in historic Atlanta on February 22-24. 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, Gunnar Hillert, 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, David Blevins, Ivar Grimstad, Simon Ritter, Heather VanCura, Stephen Chin, Simon Maple, Geertjan Wielenga, Victor Orozco, 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 am very proud to say my company CapTech sponsored DevNexus for the very first time. We had a fully manned booth that saw very good traffic and we also sponsored a well attended happy hour.

I started the conference late afternoon on the first day with 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 upcoming Java EE 8 release as well as the tentative Java EE 9 plans that Oracle shared at JavaOne 2016. 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 here (click here if you can't see the embedded slide deck):

Java EE 8 and Java EE 9 - What You Need to Know! from Reza Rahman

Later in the afternoon my former colleague Ed Burns did a deeper dive on three specific Java EE 8 APIs - Servlet 4, JAX-RS 2.1 and JSF 2.3. For those unaware, Ed is the specification lead for both Servlet 4 and JSF 2.3.

Early in the evening I delivered my talk on Cargo Tracker/Java EE + DDD titled "Applied Domain-Driven Design Blue Prints for Java EE". This talk overviews DDD and describes how DDD maps elegantly to Java EE using code examples/demos from the Cargo Tracker Java EE Blue Prints project. Below is the slide deck for the talk (click here if you can't see the embedded slides):

Applied Domain-Driven Design Blue Prints for Java EE von Reza Rahman

A screencast of my talk can be found here. Concurrent to my talk, my friend Kito Mann delivered his very cool talk on JSF and HTML 5 Web Components.

The second day of the conference in the late afternoon Ivar delivered a deep dive into the MicroProfile initiative. Concurrent to his talk Heather delivered a talk on JCP and Adopt-a-JSR. Later in the afternoon Ivar delivered a talk on the upcoming MVC specification. For those unaware, MVC was originally slated for Java EE 8 and is now a separate, community led JSR.

Overall this was another great year at DevNexus and I hope to be part of the conference next year.

DZone/Java EE Guardians Survey Results: Security

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 4 as well as Java SE 8 alignment. In this entry I'll take a look at the responses for revamping Java EE security.

Here is how the survey phrased the question:

"Java EE security is one of the last areas left to be revamped in the way most other APIs such as EJB 3 have been changed radically. As a result Java EE security is very highly dependent on things like vendor-specific GUI console wizards, vendor-specific configuration or command-line administrative tools. Pluggability, extensibility and customization is also currently challenging when the security features that already come with the application server are not sufficient.

This situation is the primary driver for the proliferation of third-party security frameworks in server-side Java such as Shiro and Keycloak. The Java EE Security API has been slated to solve these issues in Java EE 8. As an example securing a Java EE application could be as simple as writing the following annotation:

@DataBaseIdentityStore(
    lookup="java:app/MyDB", 
    userQuery="SELECT password FROM principals WHERE username=?", 
    rolesQuery="SELECT role FROM roles where username=?", ...)

How important is it to revamp the Java EE security API?".

The following graphic shows how the community responded. Support for revamping Java EE security is clearly fairly strong. 47% said it is very important while another 30% said it is important. Only about 5% said it is not important. It is the case though that support is not as strong as it is for example for Servlet 4 and Java SE 8 alignment. I think this generally makes sense. While there are decent options for Java EE security, HTTP/2 support and being able to effectively use Java SE 8 is far more foundational. If you are interested to learn a bit more about the Java EE Security API, a great place to start is the actual working specification draft.

Here are some representative comments from participants in the order that people filled in the survey: "One of the areas where no real standardization is done yet because you always need to have application server specific configuration", "The currently available security features in Java EE don't comprise a full end-to-end solution, to really secure an application one has to rely on vendor specific features", "I always found it quite challenging to work with JAAS and the vendor specific configuration required to get it to work in different containers. I am really looking forward to simpler and better integrated solutions", "Would be nice to get this into the app and out of the app's XXXX.xml and container configuration. It would seem to be a step in the right direction to making apps more fully portable".

It is important to note that in the original survey that helped launch Java EE 8, security related questions rank extremely high. Somewhat surprisingly Oracle's own Java EE 8/9 survey did not directly include any questions on Java EE security. It did pose questions on OAuth/OpenID support which ranked extremely high. Judging by Oracle's actions taken to move Java EE 8 forward, it seems they basically took for granted that Java EE security was important and the OAuth/OpenID question may have been more geared towards Java EE 9 (there are many such questions on the Oracle survey). The Java EE Security API is now moving ahead strongly to a completion date of around summer. It is sticking largely to the original scope defined for Java EE 8 while deferring OAuth/OpenID support to maintain delivery schedule (Oracle did in fact consider pulling in OAuth/OpenID support based on survey feedback).

Please do stay tuned as I further analyze 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.

Java EE Adoption Story from Armen Arzumanyan

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. Armen Arzumanyan recently agreed to share his Java EE adoption story. He has developed a number of mission critical Java EE applications in his native Armenia and beyond. One of his applications - Taxpayer3 - was so impactful that it won an international award. Armen had a number of insightful things to say about Java EE worth paying attention to. I have highlighted specific passages that really stand out.

Can you kindly introduce yourself?
My name is Armen, I am a Java developer and architect. I have about ten years of experience in Java development. I was introduced to Java while working at Lycos Europe. At Lycos we used J2EE on JBoss to develop applications in the early days of Java.

Can you describe the applications that use Java EE?
The very first application I developed from scratch in Java EE was actually a social network! I was tasked with researching the technologies to implement the front-end as well as the back-end.

The requirements dictated that the front-end and back-end should run on different servers as well as provide a rich front-end.

I tried as much as possible to utilize Java web technologies.

Back in 2008, I was pleasantly surprised with JBoss 4.2.2 - it was possible to develop a @Stateless EJB 3 based back-end without any configuration! Meanwhile, for the front-end I chose JSF 1.2. JSF allowed directly connecting web form components from a web page to Java Beans. JSF is also based on component controls which saves development time. The important part of the page layout is covered well by Facelets.

Back then, EJB 3 POJO remote interfaces made me very happy. I was able to send/receive DTOs completely transparently (no JSON, no XML).

I prepared a short demonstration to my team with the front-end running on JSF/Tomcat and back-end running on EJB 3/JBoss 4.2.2. The demo was a success and was approved.

The second significant Java EE project I helped develop from scratch was Taxpayer3. Taxpayer3 was one of the biggest Java EE applications ever developed in the former USSR. In fact the project won a top international award due to it's innovation and impact. Java EE covered all of our architectural requirements well - stable, stateless, productive and easy to upgrade.

Last but certainly not least two interesting Java EE projects I develop and support are an e-procurement system and ID-card printing system. In addition I support a very popular PKI Certificate Authority software used in lots of countries. The software is available at https://www.ejbca.org.

Why did you choose Java EE?
As a Java developer my introduction to enterprise Java started with the official Java EE tutorial. I think all Java developers should learn Java EE. Java EE gives you the fundamental skills for developing business-oriented applications.

Using Java EE and using application servers allow you to grow from a developer to an architect.

When people ask me “How did you become a senior Java developer?”, my answer is very short:

"I know Java EE"

It puzzles me that in some companies Java developers don't know Java EE and create applications using just Tomcat that are very similar to what you can do easily with what Java EE already offers out of the box. People create a lot of service layers in their applications and every component can be injected into another, no matter where is it located. But with EJB 3 you get a lot of additional power because you can make fully interchangeable local and remote interfaces which speaks to the ability to really hide your implementation behind a façade.

For me Java EE applications have always been a success: you have real statelessness, you have components, you have REST, you have remote calls, you can easily upgrade from version to version, you never need much configuration, you are focused only on development and on business logic.

Another powerful capability is Message Driven Beans which allow you to easily enable asynchronous messaging.

One interesting fact I am finding out is that I have never really developed monolithic applications! In the least my back-end has always been isolated and interacts with the front-end via DTOs. With Java EE you are not limited to just REST and JSON, which some enterprises still don't accept as a format. For example you could easily use SOAP or EJB remoting instead!

Once in an interview I got asked “Which version of JBoss have you used?”. I answered “JBoss 4.2.2, 4.2.3, 5.1 and 7.1". The interviewer replied “You are hired".

Nowadays with the microservices trend, WildFly Swarm looks very interesting. The framework enables you to develop microservices with JSF/PrimeFaces/Java EE.

How do the applications use Java EE?
In production I use a JBoss/EJB 3/JMS + MySQL-PostgreSQL-Oracle DB combination. Pure front-end parts with JSF run under Tomcat or JBoss.

How was your general experience with Java EE? Would you use it again?
I am using different technologies in different projects. Java developers should always explore a wide variety of solutions. But not understanding Java EE is like losing half of Java for no good reason.

Trying to compare technologies with each other is unwise. Instead we should compare technologies with project requirements, but you won't find a future that doesn't include the Java EE technology stack.

How can people contact you if they have questions?
My email is armen dot arzumanyan at gmail dot com and you can follow me on GitHub at https://github.com/armdev.

New Java Community Process (JCP) Membership Types and What They Mean

Last year the Java Community Process (JCP) introduced a couple of pretty important new membership types. Ever since Java EE 5 the community has played a larger and larger role certainly in shaping Java EE standards and these new membership types are important enablers in the same direction. In this post I'll explain the new membership types and what they actually mean. I'll also explain how I and the Philly JUG have used these new membership types.

The Existing Membership Types
Before getting into the new membership types I think it helps to explain what the existing membership types were. Before last year there was really two ways of joining the JCP - either as a company or as an individual. Company membership types are the original kind of JCP membership type. As scary as it is, this is basically the most common membership type for most standards bodies out there (yikes). Thankfully this has been the least common type of JCP membership for a long time.

However, even if you did want to join the JCP as an individual, you needed official permission from your company. This is a real hurdle for many people and I personally know of cases where people could not join the JCP exactly for this reason. As a long-time self-employed independent consultant this was a non-issue for me (I simply had to give myself permission to join :-)). This is how I served as an expert on the EJB 3.1, Java EE 6, JMS 2, Java EE 7 and EJB 3.2 expert groups. I believe I have been one of the most active members of those expert groups.

Either as an individual or a company, you are basically considered a "full member". That means you can do pretty much anything in the JCP - including submitting your own JSR, becoming a specification lead, becoming an expert or running for a spot on the executive committee. In case you are wondering this also includes legally recognized non-profits like Apache.

Associate Member
The new Associate membership type is basically the same as the individual membership I've used for such a long time with one big exception. In order to join as an Associate member, you don't actually need permission from your company. This does come with some limitations that I don't think matter that much. You can't become a specification lead. You can't run for the JCP executive committee. Indeed you don't get to be an "expert" on a JSR either. You can however become a "contributor" to a JSR.

In practice the difference between a "contributor" and an "expert" on a JSR is pretty meaningless for most people. As a mere "contributor" you basically can't write specification text or contribute code to the compatibility tests (TCK) or the reference implementation (RI). You can do everything else like review specification work and participate in discussions. The truth of the matter is that I am one of the most active contributors in most of the Java EE JSRs I have been on and this is basically all I did anyway. As a result, I've actually chosen to join the JCP as an Associate member instead of  a full member for this reason. I am now a "contributor" to Servlet 4, Java EE 8 and Java EE Security. I still get to do exactly what I've done for years and get credit for it in the specification document.

To be honest, it would have been easy enough for me to get permission from my company to join as a full member. The reason I chose not to do that is because there wasn't a need and I also wanted to encourage others to do exactly what I did. This is particularly important for JUGs and Adopt-a-JSR. I'll explain more in the next few sections why this is.

Partner Member
Besides joining as a fully legally recognized entity, non-profits can now also join as Partner members. Very simply put, this is basically intended for Java user groups. Many of the larger Java user groups are actually legally recognized non-profits. For these JUGs, joining as full members is perfectly fine. Most JUGs in the world are not legally recognized entities. These JUGs can now join the JCP as Partner members. Partner members do have limitations. They can't become specification leads. They can't even join a JSR as an expert or a contributor. They can however do one very important thing - run for a seat in the JCP executive committee.

At the Philly JUG, we did not opt to become a legal entity yet. It's just too much hassle with not enough of a benefit for us. As a result, the Philly JUG has joined the JCP as a Partner member. We are not running for the JCP executive committee yet, but we might.

Adopt-a-JSR
It's important to understand how all of this relates to Adopt-a-JSR. The first thing to understand is that you can participate in Adopt-a-JSR without even being a member of the JCP. The issue is that you really don't get recognized in the specification itself as either a contributor or an expert (but the lead still can make a special mention if they want). Your JUG does get listed on the Adopt-a-JSR JUGs page.

A much better way to go is to adopt a JSR, get your JUG registered as a JCP Partner member and get JUG members to become official contributors to the JSRs you are adopting as JCP Associates. This can all be done without any company being involved. This is exactly what the Philly JUG has done. The Philly JUG is now an adopter of Java SE 9, Servlet 4, Java EE 8 as well as Java EE Security.

I hope this writeup inspires you to join the JCP using the new membership types. In the many years that I've worked in the JCP, the oddest part has been the tiny number of exceptional people that actually participate actively. This really needs to change if Java is to remain successful. You need to be a part of that change.

If you have any questions on any of this, don't hesitate to reach out. I'll try to help as much as I can. One resource that might help is the JCP page on membership types.