Hi,
On Thursday, May 22, 2014, Eran Medan <ehrann.mehdan_at_gmail.com> wrote:
>
>
> 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.
>
Well, the startup I'm working for at ZEEF.com is using Java EE ;)
> (dominated by Rails, Django, Play, Node.js etc)
>
I always wonder if those actually dominate, or that maybe places
like hackernews give the impression that these dominate?
If Rails for instance would dominate, then why doesn't Ruby dominate in
popularity rankings like Tiobe? See
http://www.tiobe.com/index.php/content/paperinfo/tpci/Ruby.html
Specifically within Java, JSF typically ranks high within several surveys
(see e.g.
https://henk53.wordpress.com/2011/10/12/reply-to-comparing-java-web-frameworks).
So if you take a look at language popularity indicators you'll see that
Java is nearly always within the top 3 languages (see e.g.
http://stackoverflow.com/tags and
http://redmonk.com/dberkholz/2014/05/02/github-language-trends-and-the-fragmenting-landscape)
and then within Java it are Java EE technologies like JSF that are almost
always in the top tier.
While I do agree that Rails and others introduced a couple of interesting
concepts that Java EE can learn from (in fact JSF has indeed been inspired
by things like the flash from rails), it might well be the case that many
frameworks are only temporarily popular at hackernews.
While a lot of frameworks (not necessarily the ones you listed) have come
and gone, Java EE has been a rather stable factor for well over a decade.
In 2003 lots of companies were building stuff on Java EE, and today still
lots of companies do. It's the kind of longevity that many frameworks that
are currently hot on hackernews still have to prove.
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)
>
> I'm not entirely sure that Java EE needs two or even more competing web
frameworks. I think this will only increase confusion and makes Java EE
seems less like an integrated framework. There's a fierce competition in
the Java web framework space already. Does Java EE really needs to compete
within itself?
And where does it end? Some people may think that GWT is *the* approach,
while others are maybe more convinced that Node.js has it right, and yet
others think AngularJS is how things should be done. It would be rather
chaotic to say the least if Java EE included GWT, Node.js and AngularJS
clones together with JSF and a Spring MVC.
> - 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)
>
> While there may indeed be a difference in feature set vs ease of use
between WebLogic/WebSphere and Tomcat, I don't really see why people
wouldn't want to setup GlassFish, but would want to setup Tomcat.
Just like Tomcat, GlassFish is a download and unzip. It starts up in a few
seconds and there's nothing to install or configure before that. It's the
same thing with JBoss EAP/WildFly, TomEE, Geronimo and a few others. They
are all open source, have reasonable download sizes, are unzip == installed
and start up fast. JBoss EAP/WildFly starts in about a second which is in
practice almost indistinguishable from Tomcat's startup time.
And even IBM has a lightweight (but closed source) server out that's
currently a Web Profile+ installation (I did a review of that here:
http://arjan-tijms.blogspot.com/2013/06/trying-liberty-855.html).
So for a simple web app, but honestly also for most complex web apps
there's really no difference between setting up Tomcat and GlassFish/JBoss
EAP/WildFly/etc...
That said, I think it might be worth considering whether it doesn't make
sense to provide an embedded Java EE server that you can ship inside a war
and effectively takes over the server on which the war is deployed.
In an ideal world this should not be needed. The people in a team that
decide which libraries of the application can be upgraded to which version
should IMHO be the exact same people that decide which parts of the
application server can be upgraded, but I know that in practice this is
unfortunately not always the case.
The Java EE 8 survey already asked for a full embedded Java EE server for
testing purposes. It may be a small step from there to have an in-war
application server.
> - Database migrations and deployment automation. Ability to deploy to
> any app server automatically without any proprietary APIs,
>
> This has been discussed on this list a while back. Known by few, but Java
EE had this feature for a long time via JSR 88. For reasons that are not
entirely clear anymore JSR 88 was largely ignored by most vendors (beyond
the mandatory implementation for Java EE of course) and tool builders
alike. Even though it was part of Java EE for a long time, I don't think
many end users know of its existence.
Because of the above JSR 88 was eventually pruned from Java EE.
There is still Arquillian and Cargo though, which both via the use of
plug-ins can start/stop and deploy/undeploy to any supported server.
> However in the official JAX-RS implementation, it seems to be targeted
> only for web services.
>
It's a restful API for building web services after all. Why should it
target anything else?
I understand the feeling, but there's also JAX-WS, that's also only
targeted at web services (but of the SOAP variety, see e.g.
http://tomee.apache.org/examples-trunk/simple-webservice/README.html). If
JAX-RS also becomes an MVC framework, should JAX-WS not perhaps also become
one?
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.
>
Maybe instead of making JAX-RS an MVC framework, a better option would be
to elevate the @Path annotation to Servlet or common annotations such that
the entire platform can use it?
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.
>
For OmniFaces we test a lot on TomEE and like any Java EE implementation
CDI generally just works.
Kind regards,
Arjan Tijms