Antonio Goncalves is a senior software architect living in Paris. Initially focused on Java development since the late 1990s, his career has taken him to different countries and companies where he works now as a Java EE consultant in software architecture. As a former BEA consultant he has a great expertise in application servers such as Weblogic, JBoss and, of course, GlassFish. He is particularly fond of Open Source and is a member of the OOSGTP (Open Source Get Together Paris). He is also the co-creator of the Paris Java User Group and talks on Les Cast Codeurs podcast. Antonio wrote a first book in French on Java EE 5 back in 2007. Since then he has join the JCP and is an Expert Member of various JSRs (Java EE 6, JPA 2.0 and EJB 3.1). He then published a second book for Apress: Beginning Java EE 6 Platform with GlassFish 3. For the last years Antonio has been talking at international conferences mainly about Java EE, including JavaOne, The Server Side Symposium, Devoxx, Jazoon… He has also written numerous technical papers and articles for IT Web sites (DevX, JaxEnter) or IT magazines (Programmez, Linux Magazine). Antonio is a DZone MVB and is not an employee of DZone and has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

My Java EE 8 Wishlist

07.18.2013
| 15643 views |
  • submit to reddit

 

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 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)

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:

Published at DZone with permission of Antonio Goncalves, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jeff Zhang replied on Tue, 2013/07/23 - 9:21pm

My wish list:

  1. General security framework
  2. CDI everywhere
  3. Templating inspirated from other
  4. Multi-tenancy support on layers
  5. Open TCK
  6. Caching
  7. Better remoting call with other language
  8. Clear instruction about service, composite, constraint, concern and sideeffect

Shahzad Badar replied on Wed, 2013/07/24 - 6:19am

 I would like to add Multi-tenancy support

John Hyaduck replied on Wed, 2013/07/24 - 10:37am


- Tail Call Optimization/TCO.  So Clojure and Scala no longer have to fake this with the resulting improvement in performance and encouragement for recursive design.  It would be great if Java 8 would be the gateway for less actual Java but more professional functional solutions leveraging the JVM. 

Jonathan Fisher replied on Sat, 2013/08/03 - 10:48am

For the love of god, REMOVE old APIs. Stop implementing new syntactic language sugar until the damn API is cleaned up. That is the main complaint against Java: complexity and the myriad of crappy ways to do things still exists. If you can't afford to upgrade your legacy apps, just don't do it, no one is holding a gun to your head!

Here's a shortlist of APIs to purge completely:

java.util.logging (standardize the SLF4J api)

java.ejb (we have CDI now)

javax.jms (replace with JMS 2.0)

javax.management.jmx (JMX is incredibly important, but the API was designed to be way to damn complex. Simple annotations like TomEE does has would be far more useful)

javax.mail (Face palm)

javax.resource.spi (Probably the most important Java API, but the hardest to understand)

javax.jws.WebService (Why, oh why, so difficult)

Here are other things I consider critical:

0) Make a @Transactional CDI annotation

1) Most all checked exceptions should be converted to runtime exceptions.

2) Implement a @ViewScoped in CDI. 

3) JSF3.0. Have it be stateless by default. Component behaviors, such as validators, are processed on the client first in JavaScript. Make JSF 'pretty by default' with a Bootstrap like theme.

4) Reimplement some of the specs using CDI. For instance, JAX-RS, which has it's own injection mechanism, should use CDI under the hood.

5) Implement some sort of @Asynchronous call for CDI

6) Make it a goal to reduce the standard Java API size by half? Get rid of crufy APIs. There's a lot of them.

7) Getters/Setters. No. Add a couple of language keywords:

"public readable String myString"

"public writeable String myString"

"public String myString"

Easily checked by a compiler and an IDE.

8) Standardize the Jersey Client API. 

9) This code should be possible:

@Inject
Instance<DeliveryEndpoint> allEndpoints;

allActiveEndpoints.select(ActiveEndpoint.class);

in addition to what you have to do now:

allActiveEndpoints.select(new AnnotationLiteral<ActiveEndpoint>(){});

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.