My Java EE 8 Wishlist
My Java EE 8 Wishlist
Join the DZone community and get the full member experience.Join For Free
Learn how to stop testing everything every sprint and only test the code you’ve changed. Brought to you by Parasoft.
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
- Enterprise services and stereotypes
- One container / one POJO / several services
- CDI, CDI, CDI
- WAR is the new EAR
- Configuration and staging
- Some stuff from/in Java SE
- 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.
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.
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.
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)
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 the entire 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)
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).
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.
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 ?
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:
Published at DZone with permission of Antonio Goncalves , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.