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.

Saturday, March 18, 2017

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.

Friday, March 17, 2017

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.

Thursday, March 16, 2017

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

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):
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.

Monday, March 13, 2017

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 4Java 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 it's 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.

Friday, March 10, 2017

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):

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):

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.

Wednesday, March 08, 2017

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

Sunday, March 05, 2017

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.

Thursday, March 02, 2017

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