The most popular upcoming Java EE 8 technologies according to ZEEF users

-
I maintain a page on zeef.com about the upcoming Java EE 8 specification. On this page I collect all interesting links about the various sub-specs that will be updated or newly introduced in EE 8. The page is up since April last year and therefor currently has almost 10 months worth of data (at the moment 8.7k views, 5k clicks).

While there still aren't any discussions and thus links available for quite a couple of specs, it does give us some early insight in what's popular. At the moment the ranking is as follows:

Position Link Category
1 Java EE 8 roadmap [png] Java EE 8 overal
2 JSF MVC discussion JSF 2.3
3 Let's get started on JSF 2.3 JSF 2.3
4 Servlet 4.0 Servlet 4.0
5 Java EE 8 Takes Off! Java EE 8 overal
6 An MVC action-based framework in Java EE 8 MVC 1.0
7 JSF and MVC 1.0, a comparison in code MVC 1.0
8 Let's get started on Servlet 4.0 Servlet 4.0
9 JavaOne Replay: 'Java EE 8 Overview' by Linda DeMichiel Java EE 8 overal
10 A CDI 2 Wish List CDI 2.0

If we look at the single highest ranking link for each spec, we'll get to the following global ranking:

  1. Java EE 8 overal
  2. JSF 2.3
  3. Servlet 4.0
  4. MVC 1.0
  5. CDI 2.0
  6. JAX-RS 2.1
  7. JSON-B 1.0
  8. JCache 1.0
  9. JMS 2.1
  10. Java (EE) Configuration
  11. Java EE Security API 1.0
  12. JCA.next
  13. Java EE Management API 2.0
  14. JSON-P 1.1
Interestingly, when we don't look at the single highest clicked link per spec, but aggregate the clicks for all top links, we get a somewhat different ranking as shown below (the relative positions compared to the first ranking are shown behind each spec):

  1. Java EE 8 overal (=)
  2. MVC 1.0 (+2)
  3. JSF 2.3 (-1)
  4. CDI 2.0 (+1)
  5. Servlet 4.0 (-2)
  6. JCache 1.0 (+2)
  7. Java (EE) Configuration (+3)
  8. JAX-RS 2.1 (-2)
  9. JMS 2.1 (=)
  10. JSON-B 1.0 (-3)
  11. Java EE Security API 1.0 (=)
  12. JCA.next (=)
  13. Java EE Management API 2.0 (=)
  14. JSON-P 1.1 (=)

As we can see the specs that occupy the top 5 are still the same, but whereas JSF 2.3 was the most popular sub-spec where it concerned a single link, looking at all links together it's now MVC 1.0. The umbrella spec Java EE however is still firmly on top. The bottom segment is even exactly the same, but for most of them very few information is available so a block is basically the same as a link. Specifically for the Java EE Management API and JSON-P 1.1 there's no information at all available beyond a single announcement that the initial JSR was posted.

While the above ranking does give us some data points, we have to take into account that it's not just about the technologies themselves but also about a number of other factors. E.g. the position on the page does influence clicks. The Java EE 8 block is on the top left of the page and will be seen first by most visitors. Then again, CDI 2.0 is at a pretty good position at the top middle of the page, but got relatively few clicks. JSF 2.3 and especially MVC 1.0 are at a less ideal position at the middle left of the page, below the so-called "fold" of many screens (meaning, you have to scroll to see it). Yet, both of them received the most clicks after the umbrella spec.

The observant reader may notice that some key Java EE technologies such as JPA, EJB, Bean Validation and Expression Language are missing. It's likely that these specs will either not be updated at all for Java EE 8, or will only receive a very small update (called a MR or Maintenance Release in the JCP process).

Oracle has indicated on multiple occasions that this is almost entirely due to resource issues. Apparently there just aren't enough resources available to be able to update all specs. Even though there are e.g. dozens of JPA JIRA issues filed and persistence is arguably one of the most important aspect of the majority of (web) applications, it's just not possible to have a major update for it, unfortunately.

Conclusion

In general we can say that for this particular data point the web technologies gather the most interest, while the back end/business and supporting technologies are a little less popular. It will be interesting to see if and if so how the numbers will change when more information become available. Java EE Management API 2.0 for one seems really unpopular now, but there simply isn't much to measure yet.

Arjan Tijms

Comments

  1. UnknownJanuary 24, 2015 at 2:30 PM

    I thought EJB will be merged with CDI. It is interesting how MVC will compete with JSF.

    ReplyDelete
    Replies
    1. Arjan TijmsJanuary 24, 2015 at 3:32 PM

      >I thought EJB will be merged with CDI.

      In a way that's indeed what has been asked for and what several spec leads have indeed hinted at.

      The idea though is not so much to do a full scale merging of the EJB spec into the CDI spec, but to look at the most useful features from EJB and reimplement them *on top* of CDI.

      One of the best existing examples of this is JTA's @Transactional, which resides within the JTA spec but builds on CDI and interceptors. For Java EE 8 I hope to see things like @Asynchronous being implemented by the Concurrency spec and have it too build on CDI.

      Just moving or merging things into CDI itself is not likely the best way to go, since we'll end up with exactly the same thing again but under a different name.

      >It is interesting how MVC will compete with JSF.

      It's a touchy topic. There's an enormous amount of competition in the web framework space already. I personally don't feel there was much need for Java EE to compete internally with itself, but alas, that ship has largely sailed.



      Delete
  2. UnknownJanuary 24, 2015 at 9:28 PM

    This comment has been removed by the author.

    ReplyDelete
    Replies
    1. UnknownJanuary 25, 2015 at 12:50 AM

      (edit) How I see it: EJB specification is just about services it provides. There is no "EJB component" and it's lifecycles. We are just assigning services to CDI managed beans.

      >>It is interesting how MVC will compete with JSF.
      >It's a touchy topic. There's an enormous amount of competition in the web framework space already. I personally don't feel there was much need for Java EE to compete internally with itself, but alas, that ship has largely sailed.

      I think the same, I have already put so much work to learn JSF...

      Delete

Post a Comment

Popular posts from this blog

Jakarta EE Survey 2022

-
At OmniFaces we poll the community from time to time and again about Jakarta EE (previously Java EE) and related technologies. With the transfer of Java EE to Jakarta EE now fully completed and Jakarta EE 10 released , people are now starting to think about Jakarta EE 11 , the second Jakarta EE feature release. As such it's a good time to poll the community again. This year we're doing so in cooperation with OmniFish . In the 2022 edition, there are 4 categories of questions again: Current usage of Jakarta EE Servlet containers APIs related to Jakarta EE The future of Jakarta EE Compared to 2020, we simplified some of the questions once more; again omitting some of the less popular options to make it more manageable. We kept the questions about the future of Jakarta EE and MP together as this issue still isn't resolved. We also ask about the preferred Jakarta EE cadence. As Jakarta EE 10 is the first feature release, we haven't really established a cade...
Read more

Implementing container authentication in Java EE with JASPIC

-
This article takes a look at the state of security support in Java EE 6, with a focus on applications that wish to do their own authentication and the usage of the JASPI/JASPIC/JSR 196 API. Update: the further reading section has been moved to my ZEEF page about JASPIC . This contains links to articles, background, questions and answers, and more.   Declarative security is easy In Java EE it has always been relatively straightforward to specify to which resources security constraints should be applied. For web resources (Servlets, JSP pages, etc) there is the <security-constraint> element in web.xml, while for EJB beans there's the @RolesAllowed annotation. Via this so called 'declarative security' the programmer can specify that only a user having the given roles is allowed access to the protected web resource, or may invoke methods on the protected bean. The declarative model has a programmatic counterpart via methods like HttpServletRequest#isUserInR...
Read more

Counting the rows returned from a JPA query

-
Despite being almost ten years old, the JPA specification to this day has rather poor support for basic paging/sorting/filtering. Paging/sorting/filtering is used in a lot of (CRUD) applications where the result from a query is shown in a table, and where the user can scroll through the results one page at a time, and where this result can be sorted by clicking on any of the table column headers. In order to support this a number of things are generally needed: The total number of rows (or entities) in the full result must be known There should be support for an offset in the full result and a limit for the amount of rows that will be obtained The column (attribute) on which to sort must be dynamically added to the query Search expressions must be dynamically added to the query As it appears, only offset/limit is directly supported in JPA. A sorting column can only be added dynamically when using the overly verbose and hard to work with Criteria API. Search expressions...
Read more