Johan Vos started to work with Java in 1995. He worked on the Java Linux port with the Blackdown team. He has been doing Java consulting and development for a number of customers in completely different areas. Over the years, he has been active in a number of Java-based community projects, e.g. OSGi, the Glassfish project and Johan is a DZone MVB and is not an employee of DZone and has posted 22 posts at DZone. You can read more from them at their website. View Full User Profile

It's Time to Make a Decision

  • submit to reddit

This blog-entry is cross-posted to the Devoxx website, as I am the track-lead for this year's server-side track.

For the Java Enterprise world, 2014 is the year in-between. The Java EE 7 spec has been launched last year, and the Java EE 8 spec won’t be released this year. At Devoxx, we’ll be looking back and forward. For some companies, it is time to decide when and how to migrate to Java EE 7. For the Java Community Process, it is time to decide what should go in Java EE 8.

While the Call for Papers is open, you are very welcome to submit your proposal on a session, BOF, TIA, Quicky. The Devoxx audience will be very interested to hear your opinion on a number of areas:

  • How does Java EE 7 work in practice?
  • What is the status of Java EE 8? Which JSRs will be addressed?
  • What other server-side frameworks or components are improving (e.g. Spring) and why should the server-side developer bother about this?

Now that the first implementations of Java EE 7 are available, we would like to hear how it really works. Are there stories that show real-world numbers about productivity or performance gains, about integration with other technologies (e.g. HTML 5)? Submit them. We are not really looking into general overviews of Java EE 7 technologies, as those are already covered. But there might be a specific technology that really made a huge difference for you, and that you want to share with other developers.

Work on the Java EE 8 specifications has started, so the time is now to influence the specification. Do you have interesting ideas about something that is missing in the current Enterprise Specification? Or do you think a particular JSR is missing something important? Are there other, non Java EE technologies that are becoming more and more relevant? As you know, Devoxx attendees don’t want to hear ideas only, they want to see solutions and code. It doesn’t have to be Java EE 8 related, as long as you think there is a new technology that makes the life of the server-side developer easier or more interesting, submit a proposal.

We already received a large number of interesting proposals. The program committee will have a very difficult job but you are very welcome to make it even harder.

Published at DZone with permission of Johan Vos, 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.)


Grzegorz Grzybek replied on Wed, 2014/06/25 - 1:28am


it is time to decide when and how to migrate to Java EE 7.

I have an impression that we no longer have to migrate. Migration is difficult word in Enterprise because it usually connected with moderate-huge effort which doesn't carry any business value. Migration is usually a fun task for Developers or it's an activity related to necessary upgrade of Application Server (usually because company X no longer supports version Y).

I have a feeling that developers prefer looking at what next JavaEE provides (what versions of API) and just use it in normal flow (let's update Bean Validation or switch from Jackson to javax.json API.

Both Firefox and Chrome switched from huge announcements to just upgrading on week-to-week basis. Maybe it's time to switch to that model with JavaEE? Or as someone's written - dump the umbrella entirely?

Are there other, non Java EE technologies that are becoming more and more relevant?

Yes - Angular.JS - whatever Oracle will do, it won't embrace this model and hide it under JSF components... The very Angular.JS is a proof of this - it's natural evolution of the ideas Google had with web applications. GWT is no longer (and won't ever be) cool. Now it's natural to write for the browser using language that browser understands.

Grzegorz Grzybek

Jonathan Fisher replied on Wed, 2014/06/25 - 10:43am

The TLDR: Stop trying to migrate apps. Stick with your current server version.

Every time I've seen a company try and migrate an up a server or JEE version, it's a painful exercise and offers little business value. Don't do it. Stick with your old app server and save your efforts for an application rewrite which will come eventually anyway.

When it comes time for the rewrite, if you haven't learned the lesson: no matter what your vendor tells you, do not bind against their custom APIs or their jars. Use pure vanilla JEE. The only jar your developers should use is the official javaee-api.jar and nothing from your server vendor.

Jonathan Fisher replied on Wed, 2014/06/25 - 11:21am

Which brings me to my next point... The TLDR: Backwards compatibility in JEE the way it's done currently is ridiculous.

EJB3 was a fundamental change in JEE. A migration to EJB3 was a large effort, which improved simplicity of your apps by offering very basic dependency injection and simple remoting. If you ported your app, that would have been about 4-5 years back. 

Fast forward, CDI is a fundamental change in JEE. And now that CDI is transactional, you can pretty much get rid of most of EJB3. Again, if you rewrite, this is a huge paradigm shift which requires significant effort. (How long will CDI be good for? 4 years? Not sure, Java8 Lambdas change a few things, but in all likelihood CDI is hear to stay forever with the spec being refined.)

So... You're either porting your apps every 4 year voraciously, or you're taking your old apps and trying to run them on a newer server every 4 years (slogging through problems if your developers weren't careful).

In the mean time, we have "official" APIs in the javaee-api jar dating back to EJB 1.2 and JSF 1. This crates a huge signal-to-noise ration for newbies trying to get into JEE. A new person  when confronted with the complexity of the javaee-api jar would be more inclined to look to other languages, draining the JEE ecosystem of young recruits. (Yes, I'm very opinionated on this point: we need fresh people to join and use JEE).

I think the solution is what we did with the "web-profile" specification. Get rid of all the cruft and crap APIs and push people towards that spec, call it "JEE-light" or something. It would need it's own spec api jar. Then, everyone that wants to go down the path of porting will have another spec (likely fulfilled by vendors) called "JEE-full" which encompasses as many older APIs as possible. This would have it's spec api jar. 

I think this approach would accelerate JEE. On the "light" side, we could have refreshes every 1.5 years and the "full" side we could stick to the current cycle of about 3 years. Ideas that people actually used would make it to full and ideas that sucked would be cut from light as quickly as possible.


Neil Bartlett replied on Wed, 2014/06/25 - 12:20pm

 JavaEE 8 needs to be modular, based on OSGi. If the EG doesn't do this then they will have failed and should hand the keys over to somebody competent.

Comment viewing options

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