Java

Java EE 8 Whislist

Back in 2011 I wrote a blog post about what I wanted to have in Java EE 7. Java EE 7 has been released, some of my Java EE 7 wishes have been fulfilled (Flow management and Batch processing),  books have started to be published, and now it’s time to start thinking of Java EE 8.  Arjan Tijms has already started thinking and expressing his wishes on his blog… so I thought of doing the same.

Here is what I would like to have in Java EE 8 :

  • More transparency and cohesion in the JCP
  • Opened TCK
  • No buzzwords
  • Caching
  • Security
  • Enterprise services and stereotypes
  • One container / one POJO / several services
  • CDI, CDI, CDI
  • WAR is the new EAR
  • Templating
  • Configuration and staging
  • Logging
  • Some stuff from/in Java SE
  • Testability
  • Standard artifacts and repositories

More transparency and cohesion in the JCP

JSRs 358 (A major revision of the Java Community Process) and 355 (JCP Executive Committee Merge) have helped the JCP to be more transparent. There are still some improvements to be made, but thanks to these moves, the JCP is not the dark room it used to be. Transparency is on its way, but I would just like to have more cohesion within Java EE.

Java EE is an umbrella specification, meaning that it embraces several specifications. The Java EE expert group does not have an easy access to these specifications and it’s hard to know what other specs are doing while you are defining Java EE. Java EE expert members should have an easier access/knowledge on the other specs. On the other hand, I think that every sub-spec lead should be in the Java EE group. Sometimes we discuss topics that have an impact on several specifications, but the lack of representative makes it difficult to implement. I would also like to be involved in defining the roadmap of a new release. With Java EE 7 Oracle (i.e. the spec lead) wanted to introduce Cloud features in the platform but most of the members were against it. So when I was doing talks about Java EE 7, I would always start saying “Oracle wants Cloud in Java EE 7, but most of the expert members don’t“. That’s not a very positive message and doesn’t bring cohesion to the group.

Opened TCK

Each spec has an implementation and a TCK… and most TCKs are not opened (I’m not even talking about open source). A TCK is supposed to test all the little details of a specification, but that’s theoretical: it’s an enormous task to test an entire spec so the TCK has some holes. This means that, as a developer, when you discover a bug in one implementation due to the lack of a test in the TCK, the best that you can do is fill a JIRA. It would be great to be able to create a new test in the TCK so every implementation could benefit from it.

No buzzwords

The JCP is here to standardize, not to innovate. Some developers go “specifications suck because they arrive too late“. And thank god they do arrive only when we have enough experiment to standardize.  So I would not like to see any Cloud, BigData or any other funny buzzwords in the next EE release. Let’s see what Google, Amazon, Heroku, CloudFoundry, Oracle, Red Hat, Cloudbees… do in terms of Cloud, put them around the table, and standardize it… but not now.

Caching

Nearly there. The good old JSR 107 (JCache – Java Temporary Caching API) nearly made it into Java EE 7. I’m pretty sure JCache will finally get into Java EE 8 and, maybe, with better integration with other specifications (we could think of having JCache as a second level cache for JPA)

Security

I’m not a security guy but I know Java EE doesn’t help. When you talk about enterprise applications you always mention security… and it’s a nightmare to implement in Java EE. There are too many specifications involved (JAAS, JACC, JASPIC) and all are too low level. Authentication and authorization services should be higher level, richer, easier to use and modern (all these specs APIs are still targetted to Java SE 4). Identity API started in 2011 but hasn’t been released yet.

Enterprise services and stereotypes

I don’t like the word Enterprise. For me, it doesn’t mean anything (we all work in enterprises, write enterprise applications, no matter if they uses Struts, Java EE, NodeJS or Akka). But because Enterprise is in the DNA of Java EE, let’s keep on using this word and define Enterprise Services.

I would like to have fine grained services available to all the platform (@Asynchronous, @Lock, @Schedule, @Startup) and use stereotypes to aggregate them. That means that most of the EJB specification should be splitled in several fine grained services (into a different spec). Then, we should aggregate services into stereotypes: for example @Stateless should be seen as a stereotype of @RequestScoped @Pooled @Transactional.

One container / one POJO / several services

Java EE is all about managing annotated POJOs in several containers. When you read the Java EE specification, it talks about EJB container, Web container and Client container. Each container allows a certain subset of services (not always easy to find which services run in which container). CDI has a container, JPA a provider, JMS a broker… As a developer I would like to manipulate POJOs with annotations in a single container. This container would then transparently delegate invocations to the appropriate underlying container. Take a POJO, annotated it with @Entity, and the container delegates persistent services to the JPA provider. This single container API will allow you to bootstrap the container (in Java SE for example) and execute any code you need, such as a Monster Component. So you deploy your code into a single container, and that’s it: all services will be available.

CDI, CDI, CDI

In Java EE 7 CDI has spread into several specifications (e.g. JSF scopes are written in CDI, JTA transactions use CDI interceptor bindings…). It has to go further in Java EE 8. For that, CDI should have an Embeddable Profile with the minimum essential services (injection, producers, disposers, qualifiers) so any spec could depend on this minimum set of services (or the all lot if needed). Combined with a bootstrap API, CDI could then be used in every spec so we could have an homogenized platform (e.g. injecting anything anywhere without wondering if it will work, observing events and so on).

WAR is the new EAR

Since the Java EE 6 Web Profile, you can now use War files to package certain components (Servlets, JSF, EJB Light…). But if you want to have JMS, connectors or scheduling, you leave the Web Profile and need the full profile. War doesn’t work anymore and you need to switch to EAR. So everything in Java EE 8 should be packaged into a single War file (ear would be only for cases were you need to package several wars into an ear). And remember that with Java EE 9 (Jigsaw), modules will finally be available ;o)

Templating

JSPs are not dead (yet) but one thing is sure, no effort has been made to modernize it. JSF is the preferred Java EE Web framework, JSPs also target the Web… but what about just having templating ? There are already several templating framework we could get inspiration from, why not having standard templates ? It would allow you to develop web pages in pure HTML if you want, but also write emails, generate PDFs to bill your customers… and thanks to the richer Expression Language it would be easy to bind variables, attributes, methods… to those templates.

Configuration and staging

Configuring a Java EE application is a real drag. The specified answer is “if you need configuration, put it in JNDI“. And then you have several XML files (persistence.xml, ejb-jar.xml, beans.xml…) to play with. Those files are packaged inside a War and it is then difficult to change the values once deployed. Configuring an application should be centralized into a single place (XML format) and values easily updatable (i.e. not packaged in the war but living outside the application). There should also be an easy way to have password encryption (fed up of having the database password in clear). Staging has been introduced in JSF (Development, Production, SystemTest, UnitTest) and should be made available to the entire platform (so you could have a different configuration per stage).

Logging

I’ve already talked about it, and I will do it again. For me, logging is the most broken part of Java EE (and Java SE too). No standard API to log, format or handle logs in 2013 is a message to the world that Java is not that enterprise ready. All of us, we work on different projects, different architectures, different databases, different servers… but WE ALL LOG MESSAGES !!! We should standardize a logging API (and if nobody uses JUL, it means that it’s not the right API) and every implementation should use this API in a standard manner. Need to increase the logs for JPA ? javax.persistence.log.level=DEBUG. Need to increase logs for EJBs ? javax.ejb.log.level=DEBUG….

Some stuff from/in Java SE

I’m sure plenty of us would like to have injection (CDI) or a descent log API straight into Java SE. But I think this will not happen. But it would be interesting to take some annotation processing or interceptions to a lower level. As Ludovic Champenois mentioned on my blog, Java EE “has moved more and more annotation processing at the container level when it starts as opposed as being pre-processed at the SDK level during development”. This will, indeed, improve deployment time dramatically (Ludovic talks about the Cloud, and deploying the same application to thousands of JVMs).

Another interesting improvement has been brought by Remi Forax. A container is basically a chain of interceptors. Your own Java EE business code is turned into proxyes or uses bytecode enhancement to provide interception. Remi proposed new keywords in Java SE 9 to have native interception (interceptable and ghost keywords). Interception would then be done at the language level without any proxys. If Java EE is all about interception, then Java SE should have a look into it.

Testability

If we agree that staging should be standardized throughout the platform, then integration tests should be easier to write. Arquillian already does a fantastic job for integration testing, but we could go further. If we manage to have a single container, and therefore a single container API, then it would be easier to write tests that start a container, lookup for components, check available services, invoke code, check that interceptors have been applied,  that Servlets have been constructed, that a Singleton has been initialized at startup by the container… And this will also benefit in writing tests for the TCK.

Standard artifacts and repositories

Tell me the groupId for the JPA 2.1 API ? Give me the artifactId for the EJB 3.2 container API ? At the moment all the Java EE artifacts are spread throughout the planet. There is not a standard naming convention when it comes to Java EE APIs. Oh, and by the way, if you know your Java EE Maze you can give me the name of the JTA 1.2 and JBatch 1.0 reference implementation. Java EE 7 has standardized deployment descriptor XML namespaces, why not having a single place with all the specs, documentation, reference implementations, TCK, artifacts…. IANAL and I know this is extremely difficult to do while the JCP is not completely an opened standard body (still governed by Oracle), but the JCP website would be a perfect place for that.

Choose your own

I’m not a Web guy, so I’m sure I’m missing some brand-new-modern-flashy web features that could get in the next release in terms of Web content/management. Do you have any other idea of what you would like to see in Java EE 8 ?

Conclusion

So, as a recap, here is what I would like to see in Java EE 8 (or 9) :

  • The JCP evolves in a more transparent way, but more cohesion within Java EE would be appreciated
  • Give access to all TCKs
  • No buzzwords in this release (no Cloud, BigData…), the JCP is there to standardize, not to innovate
  • JCache in Java EE 8
  • Easier authentication and authorization
  • Fine grained services available to all the platform
  • A single container
  • CDI everywhere to homogenized platform
  • Everything in Java EE 8 should be packaged into a single War file
  • Having templates
  • Powerful configuration, password encryption and staging
  • A standard logging API used by every implementation
  • Annotation processing or interception to a lower level
  • Integration tests should be easier to write with a container API
  • A centralized place with all the specs, documentation, reference implementations, TCK, artifacts…

The JCP has opened up. The Java EE mailing list is accessible to everybody. The Java EE 8 JSR has not been filled yet and the expert group is not already formed. It’s time to join and make yourself vocal about what you want. In this post I gave you my Java EE 8 wishlist. If you also want to see some features in Java EE 8, leave a comment or write your own blog post and I’ll make sure to reference it. It’s time to participate in creating the platform you’ll be using in the coming years.

Other Java EE 8 Whishlists

I’ll try to keep track of other Java EE 8 wishlists here:

14 thoughts on “Java EE 8 Whislist”

  1. Ultimately, Java EE should be as coherent as Ruby-on-Rails. Currently it really looks like a collection of different specs that integrate with each other to a certain degree. To be productive, one shouldn’t care about the names of the specs (CDI, JAX-RS, EJB, etc), but instead “just write” the code. Java EE could just really align itself with RoR better.

    Reply

  2. I would like see better script debugger and faster jQuery operation.

    Reply

  3. I’m missing multi-tenancy in the list. Except for getUserPrincipal(), there is no way to find out for whom the user is working and even then it would be a proprietary extension.
    I disagree about the logging. The JUL API is sound IMHO. What’s needed are enterprise-ready Handler and Formatter implementations and a decent LogManager with an extended JMX interfacet. Tomcat’s LogManager and x4juli’s extensions are good examples of what you can achieve with JUL.
    Templating can be done with Facelets themselves and for JSPs there is still Sitemesh. Besides, JSF 2.2 seems to offer a lot with respect to templating.
    @Anton: Unlike RoR, JEE offers basic standardized interfaces for very disparate domains with very disparate needs. It’s more of a library than a framework. It’s the job of other frameworks (eg Spring) to integrate and abstract those interfaces. And it’s a testament to the API designers’ skills, that the JEE interfaces are still separate, yet integrate better (CDI) and are easier to use in recent incarnations.

    Reply

    1. Even if other frameworks exist, like you say to integrate the interfaces, Java EE isn’t very productive alone. What I’m saying is that it would be über-cool to see Java EE be a self-contained, coherent, and as a result _productive_ framework alone, without the need to look for help from Spring, Struts etc etc. This is what turns people away from the Java EE stack and makes them to use Play!, for instance.

      Reply

      1. I’m not entirely sure what you’re saying here. Java EE is pretty productive already and it doesn’t need the help from Spring at all, and certainly not from Struts.

        There are some nice extensions that you can add, like PrimeFaces, OmniFaces, CODI, etc but Java EE (JSF and CDI here) were explicitly created to allow such extensions. It allows 3rd parties (PrimeFaces etc) to innovate at a fast pace, while keeping the base (Java EE) stable and standardized.

        I do agree with your previous comment that Java EE should strive to be even more integrated than it already is. But it is getting much better. J2EE 1.4 was a pretty unintegrated affair, but in Java EE 6 things are already much better with CDI integrating with EL (and thus JSF), Bean Validation integrating with both JSF and JPA, CDI scopes that can be applied to EJB beans, EJB beans can be injected with @Inject, etc etc.

        Still, people should be getting more in the mode of writing “Java EE code”, while currently people are still too much coding for say JSF and JPA, or even worse MyFaces and Hibernate.

    2. >Except for getUserPrincipal(), there is no way to find out for whom the user is working and even then it would be a proprietary extension.

      I’m curious about this. Care to explain this further?

      Reply

  4. We are planning just what you describe – “CDI should have an Embeddable Profile with the minimum essential services (injection, producers, disposers, qualifiers)” for CDI 2.0 🙂

    Reply

  5. I don’t know JUL API for logging, maybe I do but not for this name 🙂 But what do you think about DeltaSpike Exception Handling approach? It use CDI events, and make logging much easy and powerful. Combined with the messages API we can have your logs internationalized!:

    http://deltaspike.apache.org/core.html#exception-control

    I Agree that template is something we all need on the web, and the JSF template engine is just too simple for real world, the fact that the developer need manually do the composite is painful.

    Security in JavaEE is for the ones who like pain. I prefer use third part high level API’s like Seam 3 security, but the idea of the container providing security is a powerful feature wasted in Java EE, we could have federated Identity and no matter where is stored the user the developer simply don’t care, but the history is very different and worse: Every server implements different, with different capabilities, It could be standardised. Java EE Security Needs a Huge improvement. When we talk about modern client interfaces using web services like REST to communicate the history is even more painful.

    I totally agree: The WAR is the new EAR

    Configuring and Staging is a common problem to, the deltaspike project is trying to implement this too.

    By the way I agree with all post.

    Reply

  6. In Java EE 6, you can package full profile project into a single War file. We use JMS, JAX-WS and EJB scheduling in our projects and always package them as War file.

    Reply

  7. Great points!
    “One container / one POJO / several services”, specially, that would be really really nice — and closely related to many other items in the list, I think.
    I love the possibilities of the Monster Component. 🙂

    Reply

  8. I’m quite satisfied about back-end functionality but what I’m looking for is a better integration with web-frameworks.
    The community is pretty active on that side and you can found plenty of web frameworks that fits every developer’s need and taste.
    The problem is that they sometimes miss a sort of “JavaEE-contract”. Actually JSF is the fully integrated and spec-aware solution so you can use easily external libraries and even switch implementation without worrying but if I prefer a web-framework that makes me more productive or that simply fits my need more I would use it as a full-featured replacement for JSF without worrying of any “integration” problem.
    To be more precise most of community frameworks lack a full CDI implementation that makes difficult a wide integration to all the other Javaee spec. I must rely on old-style and error-prone jndi lookups, ugly code to overcome injection miss and so I lost most of the productive elements of Javaee.
    How about making a “web-framework contract” into next javaee 8 so if a web-framework (eg. ZKoss, Tapestry, ecc) respect this contract it can be used transparently it into any existing javaee app without worrying about missing CDI injection, missing scopes, or any other problem could arise?
    That is: a simple drop-in replacement for JSF.
    Hope I was clear enough.

    Cheers

    Reply

Leave a Reply