Java

Java EE 7 – I have a (few) dream(s)

If you haven’t used your RSS feed reader lately, you might have missed that Java EE 7 is starting to kick off : JPA 2.1 (JSR 338) and JAX-RS 2.0 (JSR 339) have been voted, Robert Chinnici has talked about it, some conferences have mentioned it… Java EE 7 will happen and quite quickly (Q4 2012). The main focus is the cloud. I will not talk here about the cloud, I’ll talk about everything else (well, not everything ;o)

Java EE 7 is an umbrella specification, meaning it’s made of several specifications. Its goal is to give the other JSRs a common target (here, the cloud) and to make sure these specifications interact well with each other. The Java EE 7 expert group is not responsible for all the JSRs, just the umbrella. That means if the Java EE 7 expert group wants to add something new to the platform (eg. it would be nice to have batch processing into the platform) it will not do it : it will rely on some other spec (i.e. someone else) to specify it and to interact well with the other specs.

As part of the Java EE 6 expert group, I’ve been talking with my fellow expert members about Java EE 7. Like many of them I wish Java EE 7 had new stuff. But new stuff means a new specification, which means a spec lead, an expert group, a JSR, a RI, a TCK and thousands of hours of work. It’s so much work that many JSRs have been started and never ended (inactive JSRs).

Here is a wish list I would like to see in Java EE 7 :

  • Flow management : What I really miss in Java EE is something similar to Spring Web Flow or Seam Page Flow. It would be very useful to have a new specification to standardize flow management (for JSF, of course, but something more general letting you manage different sorts of flows). That would mean JSF Managed Beans could be pruned (with CDI we don’t need JSF Managed Beans any more)
  • Batch processing : That’s also something missing. With the new Timer Service we have a rich scheduler mechanism. Wouldn’t it be time to get a Batch processing specification ?
  • Security : Security is still an issue I think. JAAS is too low level and something higher level and richer would be more appropriate.
  • Caching : Talking about inactive JSRs, this is one of them : JCache (JSR 107). We have been using cache for a decade in all the layers of our architecture. We know how to make caches, so why not specify them (JPA 2.0 introduced a second level cache because JCache was not usable).

Ok. So, what do you think of this wishlist ? Want to add something more (and I’m talking about new JSRs here, not improvements of existing ones) ? Ok, and here is the difficult question : is anybody interested in taking the lead in one of these proposals (or a different one) ?

I want to stress out that the JCP is quite an open organisation : anybody can be a spec lead or be part of an expert group. Because it’s a lot of work, it’s true that the lead tends to be taken by big companies that can pay a few employees full time. In my case I’m just an individual expert member (not a spec lead) and I do it for free on my spare time. If you want to lead a spec, you need time, time, time and more time (plus all the skills that a project leader needs). Plus, you need expertise in the area of your spec. When I talk about expertise, what comes to my mind is :

  • Flow management : someone who is involved with Spring Web Flow, Seam Page Flow, BPEL or even BPMN. Flow management is a different beast but BPEL or BPMN have a similar base.
  • Batch processing : I think of Spring Batch but also, to a certain extent, Map Reduce algorithms (useful in a cloud environment)
  • Security : someone involved with security at a large, JAAS, Spring Security, SSO
  • Caching : there are so many caches out there, but someone involved with ehCache, JBoss Cache, even Terracotta

So, any brave company/individual/university/JUG who wants to pick up something in this list and become spec lead ? Do you know someone ? Well, I have a few names in my head… but I can’t tell ;o)

Let me know

38 thoughts on “Java EE 7 – I have a (few) dream(s)”

  1. Antonio,

    I think it might be a good idea to formulate your ideas about Java EE security and see if they can be implemented as part of Seam Security: http://seamframework.org/Seam3/SecurityModule.

    The batch processing solution you wish for could also probably be a CDI portable extension? If you have the time to formulate the design notes, we can certainly see if it can be implemented as part of Resin CanDI: http://www.caucho.com/projects/candi/. I am sure the same is equally true of Seam and OpenWebBeans/CODI: http://myfaces.apache.org/extensions/cdi/index.html.

    Cheers,
    Reza

    Reply

  2. I would also be interested in seeing the JMS spec evolving. It hasn’t evolved for 10 years from what I know. There are plenty of good ideas to steal from Spring’s JMS integration (and from some other frameworks as well I’m sure 🙂 ).

    Regarding caching, you might have heard that Spring 3.1 will propose an abstraction layer for caching technologies. It will be similar to the way you use Spring for transactions.

    Reply

  3. Hey Antonio,

    the most important point of your wish list is security. An extended security model is missing in JEE 6, definitely! The others are nice, but no must-haves in my opinion.

    Unfortunately, you do NOT talk about cloud here (as you mentioned in the beginning). But I would still be interested in your opinion: What is on you wish list about cloud?

    Cloud Computing is no more just a hype, so I think JEE 7 really needs some cloud content…

    Best regards,
    Kai Wähner (Twitter: @KaiWaehner)

    Reply

    1. I mentioned that a couple of times to other JCP members and Oracle.

      There are some Oracle products like Coherence and internal projects based on it, or Terracotta, probably some stuff by VMWare, too (where they chose to participate more than let’s say for 330 which only Individual Member Bob Lee got where it is with help from Google at first 😉

      Reply

  4. Thanks for that blog Antonio. Roberto seems to say the something around caching is most certainly a target for Java EE 7 (and Coherence team at Oracle knows a thing or two about data grids and distributed caches).

    @Kai, security means a lot of things to a lot of people. It would be great to lay out what is missing specifically. Reza’s comment is probably a good start but there is so much more work to make it a JSR…
    As for cloud content, there will be some in Java EE 7 since this is the main theme. Check out http://blogs.sun.com/theaquarium/entry/java_ee_7_discussion_with for more details.

    @Michael, JMS is very much considered for a rev as part of Java EE 7

    Reply

  5. I’d love to see a refreshed version of JTA as well. Can anyone name a worse specification both from the implementor’s and the user’s point of view?

    Reply

    1. What specific changes in JTA would you like to see? I am asking because it often turns out that folks don’t really know what’s already in the JTA spec (understandable since it is a system level specification). Personally, I think JTA is a pretty mature specification since transaction monitoring is a fairly mature field.

      Reply

      1. It’s so mature I’d qualify it as rotten. I wouldn’t know where to start as to describe how bad this specification is – and I know it pretty well for having implemented it.

      2. Honestly, I’m not sure how helpful these kind of vague non-constructive remarks really are.

        Sure, JTA is a pain to implement as is any distributed transaction monitor – but what are the specific changes that need to be done that are meaningful to an end-user?

        If you feel that strongly about it, it certainly isn’t impossible to simply create your own JSR with specific design ideas?

      4. This is actually very good and well-balanced. Thanks for the honest effort and I will make sure this gets to the right hands.

        Now, that being said – personally I’m not sure any of the things you mentioned really warrant a brand new specification mostly for the reason that JTA really is a pretty low level API for most developers so none of this really has a significant impact on them. I somewhat suspect the folks in the Java EE EG will come to the same conclusion.

        However, I will keep this opinion to myself (to discuss at an appropriate time as an EG) and present your commendably detailed write-up as-is.

        Hope this is some consolation.

  7. Flow Management!!? No, No No. I hate to be harsh here, but in the age of REST, cloud, and mobile apps, etc. the new JEE needs to get out of the business of managing Web page flow. Even JSF is old school in this regard. I think it was a big mistake when the JEE spec decided to dictate the UI or how it should behave which imho lead to the failure of java on the client. Focus on the cloud, and provide a platform that allows to build scalable REST services. So again, with all due respect, let the JEE experts focus their expertise on back-end matters and please leave client/UI matters to client/UI experts.

    Reply

    1. Flow management, I didn’t talk about Web Flow Management. It would be useful to be able to navigate between JSF pages, JSP pages, Swing pages, processes, EJBs, beans…. Flow management as a all. And if we add the cloud capabilities here, it would be really helpful to manage flows between beans through a cluster (start process 1 on server 1 and then navigate to process 2 on server 5)

      Reply

      1. Thanks for the clarification, but my point still stands. Just like JEE6 main focus was overall simplification, and becoming lightweight, I believe that one of JEE7 main driver should also be becoming lighter weight still. How? By getting out of the business of UI altogether. I know that sounds drastic but I think it’s the right thing to do. There are many other things the JEE7 specs need to focus to become truly cloud based, to be distracted with UI related stuff that quite frankly JEE has no business in dealing with. So JEE7 should deprecate JSF/JSP and give these third party toolkits like GWT, JQuery, even Flash etc. equal treatment and a level playing field.

      2. I’m afraid you’ve lost me here. Investing in stop-gap RIA technologies with HTML+ around the corner does not make much sense to me; neither does the idea of deprecating the JSF/Facelet technology that clearly has a lot of momentum (not counting folks that would like to deal with the traditional action oriented web development model rather than a component based model).

      3. Hi Reza, this is where you and I disagree, or I should say this is where you misunderstand what I am trying to say. I am not trying to advocate one UI technology over another, and so should the JEE7 spec. Why should a server/cloud centric spec pick winners in something that’s client/UI centric by deciding to invest, or favor a certain a UI technology. Unfortunately though this has been the case with JEE since day one. You have a bunch of experts who are really good at designing server side frameworks and who decided that they also know a thing or two about UIs as well. So again I urge the JEE spec authors to stick to what you know best, provide equal access to all sorts of client UIs, and leave the rest to their rightful experts. What’s wrong with that approach?

      4. The problem with what you are saying is twofold. One – Java EE encompasses the web tier with JSF, JSP, Servlets, EL, etc and does so pretty successfully even considering the ultra-competitive web tier space (if you don’t think so, let’s talk about the specifics; I’m no “front-end expert” but certainly know enough to separate signal from noise and pass on anything of real substance to the future JSF, CDI, Servlet, EL or JAX-RS leads). Two – there are may UI industry experts that work on the web-tier specifications. Take a gander at the JSF 2 EG: http://jcp.org/en/jsr/detail?id=314 for example.

      5. I don’t blame you if you don’t agree with me. All I can say is thank God for Steve Jobs. It took a genius like him to finally move the industry forward in terms of user interface innovation while everyone else is busy trying to hash out yet another way to put divs, and spans on a browser page. And don’t get me started on JSF. Get back to me as soon as they can figure out how to get Ajax right.

      6. You are correct – I don’t agree with you at all. Indeed your comments seem like a redux of all the anti-JSF noise that I thought ED Burns replied to quite effectively: http://www.zeroturnaround.com/blog/ed-burns-on-why-jsf-is-the-most-popular-framework/. Personally, I’ve used JSF/Facelets in a number of projects (and yes, including AJAX enabled components that are much more pleasant to use than low-level, hack-friendly pseudo-JavaScript frameworks) and think it’s much better than any other alternative hands down.

    2. I tend to agree with you that there is a danger in standardizing too much too quickly.

      I think the best way to handle this at the moment is via third-party open source frameworks as well. However, as a bare minimum it could be useful to speak to Gavin, Ed Burns, etc about what the specific design ideas are. It’s not ideal, sure, but it would be good to get the ideas fully hashed out with JSF as a starting point.

      Reply

      1. I use Spring Web Flow on a day to day basis (I also had a quick look at Seam Page Flow) and I find it very useful. These 2 implementations are 4/5 years old, so I think there is enough background to standardize it. I agree, a first release could just focus on JSF.

  8. Modularity is a requirement for modern development. While JEE define a rudimentary modules implementation it leaks the dynamism nature of a true module system. OSGi(Eclipse)/Netbeans Platform have made Huge advancement into this field. Glassfish has started introducing hybrid enterprise applications (JEE+OSGi) I’d definitely would like to see it making it into a spec (OSGi aware CDI, OSGi bundles packaging and deployment into EAR file, Automatic enlistment of JEE Managed Beans into OSGi Registry, Injection point for OSGi services into JEE Managed beans, Transaction propagation from one side to the other…).
    Regarding JSF I’d like to be able to have a composite view from different OSGi web bundle (.web files) or bundles fragments. Most modern IDE (that implement modularity) allow UI extensibility from installed modules/plugins. For example a Facelets template would define extensions areas(HTML placeholders/Divs) that get filled from OSGi bundles. Another neat feature would be to have JSF components deployed as OSGi bundles.

    Reply

  9. @Kai,Reza,Antonio: As Alexis said in his comment, security is quite a wide domain. So what do you think is missing in JEE 6 ?
    Regarding authentication, what do you think about JASPIC (JSR 196) and the possibilities it adds to previous JAAS-only authentication ?
    This is actually a topic I’m really interested in, and I’d like to know your opinions.

    Reply

  11. From my side, just two things:

    Regarding the cache, I would like L2 cache coordination in a clustered environment (or better for the cloud) to be fully catered for in JPA 2.1 standards

    Scalability in cloud environments to be included in web.xml or application.xml, maybe can be parameterized like max 200 concurrent users per cloud instance, and give hints to the cloud engine on when to scale in, out, up, down, etc…

    Reply
  12. Pingback: Revue de Presse Xebia | Blog Xebia France

  13. I think Mike A should acknowledge that we shouldn’t need a UI expert to build a web application. The same way we don’t need a UI expert to build a desktop application.

    That said I think where JSF is somewhat lacking is that there is no specification that says what a particular component should generate and hence we can’t just drop in different components from different vendors and expect that styles etc just work. So from a UI perspective if you don’t the markup being generated then it’s very difficult for you to change that.. i.e: the UI developer has to gain expertise in JSF component design.. A spec which would enable a UI expert to change the markup without affecting the component functionality would be desirable here (this sounds like a tough problem though). Perhaps some higher level components spec for the stuff we generally use in web apps might address this.. i.e paged dataTable, sliders etc.. with hooks for the UI expert to specify markup overrides…

    Another JSR I’d like to see is wrt configuration.. Most organization have different environments that they need to deploy the same application to (i.e: dev,test,stage,production). This is addressed in some ways with JNDI but there are still problems with things like environment specific stuff in web.xml or log4j.xml… There should be some standard way of specifying environment specific configuration here rather than using build time ant techniques. I currently use a modified version of jconfig with spring to address these shortcomings but it really should be speced into JEE

    I’m +1 on flow management. I’d actually like to see a jsf component itself speced that’s capable of embedded flow management. i.e: a flow within a page…

    Reply

  14. Hi Antonio
    Sorry for the late response, I only just saw your post.

    My dream is also related to Batch jobs but with JPA.

    Currently with JPA there is no scalable way to process a very large resultset: it is unreasonable to load up 10 million records into memory in a List
    In fact I have needed to do this sort of thing in 4 out of the last 5 projects I have worked on but to do this well is not so obvious.

    One needs to either resort to raw JDBC or use a persistence provider specific extension (Hibernate has ScrollableResultSet).
    But even with ScrollableResultSet there are pitfalls: it is necessary to clear the entity manager or evict the entities regularly and the Hibernate implementation is quite buggy.

    Ideally JPA2.1 would implement this as an iterator and the Entitys would be automatically detached after the following call to next()
    (this is to allow them to be garbage collected otherwise the first level cache will keep references).

    It IS possible to implement an Iterator for doing this using ScrollableResultSet but with some restrictions (mostly relating to the aforementioned bugs).

    In JPA, something like this would be great:

    java.util.Iterator TypedQuery.getIterator()

    However there would need to be certain restrictions on the query:
    For example, if fetch joins were used then there would need to be an ordering on the primary or unique key of the entity returned.
    This is so the enity could be assembled with its children. In many cases this could be added automatically (or if this was too difficult, simply produce rubbish, or throw an exception if someone does it wrong).

    What do you think?

    Reply

  16. I think an integration between security and entities would be great. So you could mark a user entity with a username field with the @username annotation, and also @password and the server would validate against that. Also the @Groups annotation. What do you think?

    Reply

  19. I’d also like to see security bein taken more seriously from all JSRs. But I don’t think we need a new security model. We need everyone to use the current one (for example, declarative security for portlets, CDI managed beans and JPA). We need clarifications so a Login Module really works with any app server. And I would like a (new) standard to get info about the current user, say real name, e-mail and the like. The Portlet API has a start, but this should be part of JEE and not an optional spec.

    Reply

  20. Looks like you’ve been playing with the spring framework. Personally, using a third-party framework to integrate with JEE is not a problem. I really don’t see the need to have everything within JEE. Seeing constant improvements on what is already out there is good enough for me.

    Reply

  22. I want

    @NeedsAccess(create,read,write,update)

    instead of

    @HasRole(value=”MYFIXEDROLENAMEWHICHCANNOTBECHANGED”)

    Reply

Leave a Reply