[javaee-spec users] Java EE future plans as an alternative to Play/Grails/Spring/JRubyRails/Django

From: Eran Medan <>
Date: Thu, 22 May 2014 14:07:25 -0400

This is my first post to this group, please let me know if this is the
right place for this kind of feedback / question.

I really like Java EE, and I really wish it had more adoption among "non
classic EE" projects. such as new startups, SaaS products etc. (dominated
by Rails, Django, Play, Node.js etc)

There are several items I think are missing and I was wondering if Java EE
plans include any of the following:

   - MVC alternative to JSF (either Rails like or Spring @RequestMapping
   like, I think Jersey MVC is the closest in it's concept to it. I think JSF
   is great, but we need a "Rails like" alternative as well)
   - Ability to run a simple Web profile on Tomcat (easy deployment to
   Heroku / Amazon Elastic Beanstalk is crucial. People don't want to setup a
   Glassfish / WebLogic / WebSphere for a simpe web app)
   - Database migrations and deployment automation. Ability to deploy to
   any app server automatically without any proprietary APIs, and ability to
   have DB and War version handling across DEV, QA and Prod
   - Better and more official package management and dependency management

Now for the why:

*Why MVC alternative? *

I filled the recent survey, and wasn't sure what are the plans down the
road for including Jersey MVC officially (or another MVC solution)

The motivation behind my hope to see this happening is to simply get rid of
the need to use Spring, or any other MVC framewor (e.g. Play) for non
enterprise Java Web Apps
(e.g. I would like Java EE to be a real alternative for any new SaaS
startup out there. an alternative to Spring, Play, Rails, Node, Django etc)

In modern web frameworks, routing for a REST JSON web service, is done the
same exact way as routing for a view + controller (Rails, Django, Play)

However in the official JAX-RS implementation, it seems to be targeted only
for web services. E.g. if I set the JAX-RS application root on "/" then I
will have to manually compile JSPs, serve static files etc (or find out how
to forward it to the default servlet, see my related stackoverlfow question
on the topic:

If I could return a View from a JAX-RS @Path then I would not need any URL
rewriting and I will not need to rely on Spring @RequestMapping anymore.

What are the MVC "JSF alternatives" plans for Java EE 8 / 9 / future? Will
Jersey MVC make it to Java EE 8? something else?

*Why ability to run on Tomcat?*

One of the needs for it to really be a "Rails/Play/Spring killer" is
ability to publish on heroku / amazon elastic beanstalk (which means Tomcat
and not Glassfish)
For the love of God I couldn't get CDI (which is a really nice to have
feature for good architecture) to work on TomEE. basic CDI should work
without a full blown app server (or at least ablity to do it via open
source dependencies, as long as you can push it to heroku, it should be
fine. People are using Spring just because of the lack of support for some
features in tomcat e.g. CDI. it shouldn't be the case)

*Why db migrations / versioning / deployment?*

Ability to sync code + db changes between dev, QA, UAT and production is
critical. Right now I don't know of a good db migration solution for Java
EE unless you 100% use JPA and reverse DDL I guess (I'm not that familiar
with it). But I think the Rails approach for automatic db schema migrations
/ versioning is a good starting point. Ability to push an app in a standard
way (I mean not just copying it to the autodeploy folder, because each web
server has it's own convention) I am looking for a Java EE utility that
looks like "deploy_web_app myApp.war -s serverName -u user -p password
--context optionalOtherContext" that will be standard for all app servers.
as well as Java EE standardized "stop_app_server" and "start_app_server" so
automated installers can be App Server agnostic when pushing a web app to a
server. Just like JPA abstracts over DB implementation. starting stopping
and deploying should be abstracted from the actually app server.
Having nice versioning / packaging for Web Apps will allow tools like
Puppet to automate deployment of large Java EE web apps across local cloud
infra or to customers, without the need to know the intimate details of
WebLogic, WebSphere, Glassfish or JBoss. if all app servers will be
required to expose an API via Java EE extensions to start, stop deploy and
undeploy, then this will be possible

*Why better package management? *

Currently there is no standard package management in Java, or Java EE.
maven is a community project and not a real standard. it will be nice to
have something like what npm is for Node, gem is for ruby etc.
I would like to see an npm like repository with a first come first served
"simply" naming for popular Java packages. they should handle configuring
your PATH, adding anything to the /bin folder if need be, etc.
a simplified version of maven dependencies within Java EE that has maven as
a reference implementation will be nice. But also ability to install Java
based utilities like this - "jpm install foo"
this will improve adoption IMHO if people could do "jpm install
java-sample-webapp", and then "cd java-sample-webapp" and then "jpm run"
and have a working Java EE self contained web application to play with.
dependency management should be standardized in any case, and convention
over configuration, and DRY should be first priority.
I recently worked with a Puppet developer, who simple refused to learn
maven because it was way to complicated for him to pull a simple artifact
from artifactory. we moved to curl. he was expecting something like mvn
install artifact-id:version and instead had to do something like "mvn
-DartifactId=... -Dversion=... dependency:get" I lost him there :)


I really like Java, and Java EE. I think that with Java 8, a whole new
world of developers can and should be able to "go back to good old Java"
and enjoy it. Java EE 7 is way more DRY and convention over configuration
than ever before. It's very high performance, and very strong in terms of
capabilities. There is no reason why it will be only found in big
enterprises and not in Y-Combinator startups like dropbox, AirBnb, Stripe...
But I hardly see any new developments of new startups using Java EE. I see
hybrids, Spring's recent versions, Dropwizard, Grails, vertex, Play for
Java/Scala, Akka for Java/Scala, Spray etc. but I haven't encountered
anyone doing a pure Java EE project for a "modern" / recent startup in
quite a while. It has become the sole domain of enterprise applications.
And even then Spring seems to be filling a lot of gaps there. I don't think
we need Spring's overhead nor any other of the alternatives. I think Java
EE can do a huge comeback for lightweight MVC web apps, it's not that far
from there.