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.

Monday, February 13, 2017

DZone/Java EE Guardians Survey Results: Java SE 8 Alignment

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 support in Java EE 8. In this entry I'll take a look at the responses for Java SE 8 alignment in Java EE 8.

Here is how the survey phrased the question:

"Java SE 8 brings a bounty of improvements - lambda expressions, the new date/time API, completable futures, streams and the fork/join common pool. Many of these features can be used with Java EE 7, but there remains many important missing pieces.

In particular Java EE APIs like JPA, JMS, JSF and JAX-RS need to be adapted to make full use of repeatable annotations, the date/time API and completable futures. In addition the fork/join common pool and streams currently cannot be safely used in Java EE environments.

How important is it to fully align Java EE with Java SE 8?".

The following graphic shows how the community responded. Clearly developers think aligning Java EE 8 with Java SE 8 is extremely important. 66% said it is very important while 25% said it is very important. A mere 2% said it is not important. If you want to learn a bit more about Java SE 8 and Java EE, please do feel free to check out my slide deck on the topic. The deck is focused on how Java SE 8 can already be utilized in Java EE but also highlights clear gaps that can only be addressed through changes in Java EE 8.
The fact that developers feel so strongly about Java SE 8 is no surprise at all. Every reliable survey shows strong support for Java SE 8, including DZone's. The most recent RebelLabs survey shows 62% adoption for Java SE 8 - far stronger and faster than any other recent prior version of Java.
Here are some representative comments from participants in the order that people filled in the survey: "Java SE 8 APIs are great", "I've always believed that keeping EE on track with the corresponding SE release should be a very important element of every version", "The changes in SE 8 are a huge improvement for the language. EE 8 users should also benefit from these improvements", "EE should always be aligned with SE", "Java SE 8 brought the next level of language features to Java and everyone must take advantage of it", "This is the most important thing EE 8 needs to do.".

The initial Java EE 8 charter clearly mentions Java SE 8 alignment as a major theme. Historically Java EE has always played a key part in bringing Java SE features into the enterprise. A particularly salient example was groundbreaking annotations support in Java EE 5 and EJB 3/JPA. Java EE 5 was the very first mainstream technology to clearly demonstrate how annotations can be used highly effectively as framework meta-data.

Somewhat surprisingly Oracle's own Java EE 8/9 survey did not directly include any questions on Java SE 8 alignment and they have not specifically addressed the issue either. In practice at least some of the most obvious Java SE 8 alignment work seems to be moving forward for Java EE platform level common annotations, CDI, Bean Validation, JPA, JAX-RS and JSF. I have already asked for a more coordinated plan and will follow-up soon. If this is an important issue for you, please chime into the linked thread - it's very easy to do.

Please do stay tuned as I further analyze specific topics in the survey. In addition to my analysis, 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.

Monday, February 06, 2017

Morocco's First Open Source ERP Uses Java EE 7!

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 at Zeef (Zeef is also written with Java EE). Mohammed Bounaga recently agreed to share a very cool such adoption story on deftERP - Morocco's first open source ERP. Mohammed 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?
I'm Mohammed Bounaga and I'm from Ifrane, Morocco. I'm a software engineer and I have been working with Java EE for 3 years. I'm the creator and project lead of deftERP. This project is now powered by xHub, a Moroccan startup that supports and believes in open source projects, founded by Badr El Houari - Devoxx Morocco chair, Morocco JUG lead and Java Champion. We are now a small team of talented developers who are working in collaboration with the Java EE community to boost the development of this project and empower the open source ecosystem in Morocco and Africa.

Can you describe the product that uses Java EE?
After graduating from university, I decided to work full time at home on an interesting and challenging project while sharpening my software development skills. At that time, I had different project ideas including desktop and mobile applications; yet my final choice was to develop an ERP web application since I believe that enterprise applications require complex business processes and they are open for innovation and creativity and this is exactly what I was looking for. The first version of this product was a result of 18 months of hard work with ups and downs that required patience and self-motivation. DeftERP is an open source and smart ERP built with full Java EE 7 (JPA 2.1, EJB 3.2, JSF 2.2, CDI, Beans Validation, JAX-RS, JSON-P, WebSocket...). The product is currently dedicated to small businesses to help them embrace and take advantage of technology to automate their daily working process, reducing working time and energy, having a smart dashboard and some predictions to help them anticipate the future while of course increasing profit. The product currently includes 4 modules:  sales, purchases, inventory, and accounting and it's cloud ready!

Why did you choose Java EE?
I had fallen in love with Java during my university years and it has always been my first choice, which is the case with deftERP. The only issue I had when I decided to start this project was which Java web framework to adopt. I spent a couple of weeks doing some research reading blog reviews from the Java community comparing different Java web frameworks including JSF, Spring MVC, and Struts. I was really impressed by the idea behind component based frameworks and how JSF is appropriate for rapid development while still giving you flexibility and room for creativity. What is also awesome about JSF is the availability of third party libraries such as PrimeFaces and OmniFaces that empowers developers with a great set of UI components that every application needs, and finally let's not forget the fact that Java EE is not heavy anymore!

How does the product use Java EE?
The product is developed with Java EE 7. We are using JSF for the web layer with PrimeFaces as a components library. EJB for the business layer. JPA with the EclipseLink implementation for the persistence layer, WebSocket for real time notification, CDI is of course the glue that binds our application layers together with dependency injection, and we are using BeanValidation to validate our entities against predefined or custom rules (we have built a metadata programming model).
How was your general experience with Java EE? Would you use it again?
Of course yes, we were happy to know about the plans to move forward Java EE 8 during last JavaOne. We are even planning after releasing the new version to see how we can help in the Adopt-A-JSR program under the umbrella of Morocco JUG. We are also keeping an eye open on the MicroProfile initiative since we are looking forward to revamp and optimize the architecture of deftERP for a microservices architecture. At this stage we aim to include the voice of our community!

How can people contact you if they have questions?
Questions and contributions are always welcome!
If you have a similarly great Java EE adoption story to share with the community (particularly migration stories from other technologies), please do reach out.

Saturday, February 04, 2017

RebelLabs Survey Shows Java EE Still Dominant, Solid Java EE 7 Adoption

The RebelLabs Developer Productivity survey is one of the most important ones in the Java ecosystem. It is widely circulated and generally tends to have the most data points. The survey has always asked about Java EE as well as Java SE adoption. The results in the 2016 survey look encouraging for Java EE generally and Java EE 7 specifically, particularly given the seemingly perpetual nay-saying around Java and Java EE in predicable corners of our ever "colorful" industry.

The RebelLabs survey is a bit different from the similar DZone survey in that it asks participants to make mutually exclusive adoption choices. You can either be a Java EE user or a Java SE user. You are only allowed to choose one specific version of Java EE. While this may not be entirely reflective of more complex scenarios in real life, it does make the results a bit more interesting from an analytical perspective. The 2016 results for Java EE adoption are shown in the graphic below. A clear majority of developers - 58% - identified themselves as Java EE users. 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. Even more encouragingly developers seem to be solidly behind Java EE 7 - far more so than previous versions including Java EE 6. It is especially good to see the number of J2EE users at a low percentage.

It's remarkable how similar these results are to other surveys from reliable, neutral sources (the DZone survey results are in the graphic below). There has been another survey from the Vaadin team that also shows Java EE ahead of other alternatives amongst Java developers. I'll highlight those results as well soon.
While all of this is good news, the Java EE community can ill afford to rest on it's laurels even for a moment. A number of us in the Java EE Guardian community were very worried what the RebelLabs survey was going to show in 2016. This is because the survey was taken when Oracle's commitment behind Java EE 8 still remained very uncertain. In fact RebelLabs correctly noted this may be a reason for lower participant support for Java EE compared to other years and the Java EE community has hard work ahead of it.
This is wise advice for the Java EE community and a reason to continue to try our best to advance Java EE. All that being said, it is important to remember that none of these are scientific surveys in any real sense so it is always a good idea to only make high level observations around them. Scientific surveys are truly random, have representative sample sets and clearly identify participants. Most of the surveys we have are unfortunately always self-selection based and at least partially anonymous/online.

On behalf of the Java EE Guardian community it is only correct to thank everyone that indicate their support for Java EE and Java EE 7 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.

Saturday, January 28, 2017

DZone/Java EE Guardians Survey Results: HTTP 2/Servlet 4

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. In this entry I'll dig specifically into the responses for HTTP/2 and Servlet 4 support in Java EE 8.

Here is how the survey phrased the question:

"The much awaited HTTP/2 standard is now complete, was fifteen years in the making and promises to radically speed up the entire web through a series of fundamental protocol optimizations.

Servlet 4 is the primary vehicle to bring HTTP/2 to server-side Java. Beyond Servlet 4, higher level server-side Java web frameworks like JSF can also take advantage of HTTP/2 to significantly improve performance.

How important is it to bring HTTP/2 support to Java EE?".

The following graphic shows how the community responded. Clearly developers think HTTP/2 support and Servlet 4 is important for Java EE 8. 65% said it is very important while 25% said it is very important. A mere 1% said it is not important. If you want to learn a bit more about HTTP/2 and Servlet 4, please do feel free to check out my slide deck or screencast on the topic. While it is possible for server implementations to provide some level of HTTP/2 support without Servlet 4, things like server push can only be provided in a manner that developers and framework writers can rely on through Servlet 4. In addition, the Servlet 4 TCK is the only third party verification mechanism that a server actually implements HTTP/2 correctly.

Unsurprisingly, the results for Oracle's own Java EE 8/9 survey basically mirrors what the DZone/Java EE Guardians survey indicates. The graphic below shows the results of the Oracle survey. Just as in our survey, Servlet 4 is one the APIs that has the strongest support amongst all Java EE 8/9 features.
Here are some representative comments from participants in the order that people filled in the survey: "Servlet 4 and HTTP/2 are probably the most important parts of Java EE 8", "Very important as there are a lot of improvements in HTTP/2, it is the future", "I cannot imagine the next iteration of any serious web-based standard or framework not to take (full) advantage of this advance in the underlying technology", "HTTP/2 is a big step towards faster communications and applications", "HTTP/2 is the future of the web", "I develop web applications with JSF, so yes this is very important", "Clearly more than very important".

Oracle has recommitted to delivering Servlet 4 by the end of this year or sooner. Although the Oracle specification leads have clearly re-engaged in Servlet 4, progress still lags behind some other Java EE 8 JSRs. That said work on Servlet 4 is visibly spinning up as I am writing this.

Please do stay tuned as I further analyze specific topics in the survey. In addition to my analysis, I would encourage you to look at these survey results yourself and get involved in Java EE 8. You can certainly do so by becoming a part of the Java EE Guardians.

Tuesday, January 24, 2017

JSF 2.3 Public Review Starts Now!

JSF 2.3 has just posted a public review (this is the last step before the proposed final specification). Like JSF 2.2, this is slated to be mostly a minor update with various incremental features that the community has requested. Indeed the community has driven JSF 2.3 very heavily, directly committing many of the features into the Mojarra code base. Here is a summary of the features slated for JSF 2.3:
  • Alignment with the Java SE 8 Date/Time API
  • Improved CDI support
  • Formally deprecating the JSF specific bean sub-system in favor of CDI
  • WebSocket integration
  • AJAX method invocation
  • Multi-field validation
Besides the above, there are many more smaller grained changes. For details, you should check out the specification document itself (linked below). There is a nice change list at the very start of the document. The community had already been doing a nice job blogging about JSF 2.3 features - particularly folks like Arjan Tijms and Anghel Leonard. Simply Googling JSF 2.3 should go a long way to get a more detailed overview.

You can download and take a look at the draft specification from the JCP site. If you are a JSF user you should do your part by engaging actively. Here are the many ways you can 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 JSF specification user alias.
  • You can share ideas and feedback, possibly by entering issues in the public issue tracker.
  • You can read the public review specification now.
  • You can try out the reference implementation now.
  • You can write or speak about JSF 2.3 now.
  • You can encourage others to participate.
The next step is up to you. You can be a real part of Java's ongoing success yourself instead of simply being a passive consumer. If you have any questions I am happy to try to help - just drop me a note any time.

Monday, January 23, 2017

DZone/Java EE Guardians Survey Results: A Summary

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.

The Motivation and Context
Shortly before JavaOne 2016, after months of silent inactivity, Oracle announced that it was committed to delivering Java EE 8. While this was undoubtedly good news, the problem was that Oracle appeared to also wish to significantly shift the focus of Java EE 8 - basically unilaterally. Oracle's rationale was that so much time had passed since initial launch that the focus of Java EE 8 needed to be shifted. We thought the best way to ensure that was a wise thing to do is by asking the community directly through an open survey - the very same way the initial scope of Java EE 8 was formulated.

As it turns out now, the core objectives of having the survey was accomplished in more than one way. During the JavaOne time-frame, Oracle announced it's own open survey not just to determine the scope of Java EE 8, but also the scope of Java EE 9. More recently Oracle announced the results of that survey and finalized the focus of Java EE 8. Although the surveys were clearly different, the results of the Oracle survey was very similar to what the folks that took the DZone/Java EE Guardians survey indicated. Indeed the ultimate good news is that the final focus of Java EE 8 is basically aligned with the results of the Java EE Guardians/DZone survey. Perhaps that isn't mere coincidence. At JavaOne 2016 the Java EE specification leads promised to take a very close look at the DZone/Java EE Guardians survey results. If they did indeed do that the community should be humbly relieved and grateful.

The Results
The survey did well considering the short time frame that it had been open and the relatively modest resources that we had. In the end we had 800+ input points. While smaller than the Oracle survey this is enough to draw reasonable conclusions on what the community thinks about Java EE 8 scope (for context US professional surveys collect about 1000 random input points for a population size of 300 million+). The quality of the input is quite good including many thoughtful comments. For those that don't want to read through all the survey results, I'll provide a short summary:
  • The survey completion rate is 100% which shows how serious the folks that participated are.
  • Almost 70% said they were OK with follow up questions, which shows how engaged the folks that participated are.
  • There was relatively strong support for Servlet 4, Java SE 8 alignment throughout all Java EE APIs, more robust JSON support and a security API overhaul.  
  • There was reasonable support for dynamic configuration and JCache.
  • There was relatively weak support for eliminating EJB in favor of CDI, MVC, NoSQL, more reactive programming and microservices.
  • Most people want Java EE to take a relatively conservative approach to standardization and avoid hype.
  • The majority of people would like to see the Java EE release frequency accelerated.
In the coming weeks I will analyze each of these results in much greater detail. I will also put the results in the context of the Oracle survey results, Oracle's actions so far as well as other important public data such as the latest ZeroTurnaround developer productivity survey.

What Oracle is Doing
As you may be aware, Oracle promised to deliver Java EE 8 by the end of this year with an altered scope. They have also promised to deliver Java EE 9 by next year. So far things for Java EE 8 look good and it may even be that Java EE 8 will be delivered around the JavaOne 2017 time frame. The following is a summary of what Oracle is doing with Java EE 8 so far:
  • They are moving forward with Servlet 4, JSON-P 1.1, JSON-B 1.0, Java EE Security, JAX-RS 2.1 and JSF 2.3. In addition CDI 2 and Bean Validation 2 is moving forward under Red Hat's leadership.
  • Oracle is dropping Java EE Management, JMS 2.1 and MVC. However Oracle is transferring full ownership of MVC to the community. The community will move MVC forward on it's own.
  • Oracle has not stated a clear position on aligning Java EE 8 with Java SE 8. It seems most of this work will be done including changes to JAX-RS, JSF, JPA and JSON-P. I am following up on this topic in the Java EE 8 expert group.
  • Oracle had initially indicated that they would include a new configuration JSR in Java EE 8. It is a bit disappointing that Oracle is now not pursuing this JSR for Java EE 8. However, Oracle has acknowledged that this JSR is important but it is being deferred for now to deliver Java EE 8 on an accelerated schedule.
  • Oracle has not been clear about what it intends to do with JCache. However, it is already possible to use JCache in Java EE applications.
In addition to my more detailed analysis in the next few weeks 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.

Lastly, this entry would not be complete without mentioning the MicroProfile initiative. The initiative is forging ahead with a 1.1 release. It is targeting many of the features that Oracle is interested in for Java EE 9, including dynamic configuration. The idea is to make collaboration-based microservices centric products from Java EE vendors available essentially before Java EE 8 is released. We can hope that the MicroProfile efforts will converge with Java EE 9 sooner rather than later.

Thursday, January 19, 2017

JSON-P 1.1 Public Review Starts Now!

The JSON-P 1.1 (Java API for JSON Processing) specification has just posted a public review (this is the last step before the proposed final specification). For those unaware, JSON-P is a lower level JSON processing API introduced as part of Java EE 7. JSON-P 1.1 is a relatively more minor but important update that will be included in Java EE 8. Java EE 8 will also include a higher level declarative JSON binding API named JSON-B. While JSON binding is clearly important, there are many cases where a simple processing API is more appropriate. JSON-B also depends on JSON-P under the hood.

These two APIs together are extremely important in making JSON a first class citizen of the standard Java platform, just like JAXP (Java API for XML Processing) and JAXB (Java API for XML Binding) did many years ago for XML. With these two APIs in place Java developers can simply think of JSON as yet another Java serialization format. No more third party libraries and no more configuration - things will simply work out of the box when it comes to processing JSON. In my view these APIs are so critical they should indeed be moved to a modular Java SE release, much like JAXB and JAXP are already a part of Java SE.

The changes introduced in JSON-P 1.1 mostly includes staying up-to-date with JSON open standards like JSON Pointer and JSON Patch. There is also some Java SE 8 alignment work included in JSON-P 1.1. A very good resource for an introduction is a slide deck from specification lead Dmitry Kornilov as well as Werner Keil from the community presented at Java2Days 2016 (click here if you can't see the embedded slide deck).


You can download and take a look at the draft specification from the JCP site. You should do your part demonstrating first hand that JSON-P 1.1 is a critical standard for Java - by engaging actively. Here are the many ways you can 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 JSON-P 1.1 specification user alias.
  • You can share ideas and feedback, possibly by entering issues in the public issue tracker.
  • You can read the public review specification now.
  • You can try out the reference implementation now.
  • You can write or speak about JSON-P 1.1 now.
  • You can encourage others to participate.
The next step is up to you. You can be a real part of Java's ongoing success yourself instead of simply being a passive consumer. If you have any questions I am happy to try to help - just drop me a note any time.
Home   |   Site Map   |   Resume   |   Projects   |   Blog   |   Downloads   |   Links   |   Contact