[eranation]

Modern Java EE has taken a lot of influence from other web frameworks. It is now much more convention over configuration than it used to be. I think it just lacks a new MVC module as an alternative to JSF. If only jersey 2.0's mvc templates were added to the core, I would have considered it instead of other alternatives (e.g. Adding routing to a view from JAX-RS, right now it's not trivial and meant mostly for "services" e.g. API methods vs JSF for your friendly neighborhood MVC. I think JAX-RS is much more friendly and familiar to people coming from other web frameworks. JSF is not too, well, RESTful and feels a little outdated to me, although it's very powerful...)

(Dropwizard uses JAX-RS by the way if I'm not mistaken)

Now with Java 8, Java EE is quite a powerful and productive framework, and the performance is pretty predictably just awesome.

[mikehaggard]

> I think it just lacks a new MVC module as an alternative to JSF.

In Java EE 8 such a new MVC framework is indeed coming. From the same startup the article uses as an example: https://mvc.zeef.com/manfred.riem

That page is from the MVC 1.0 spec lead (Manfred Riem). It's going to be strongly based on JAX-RS and mimicking how Spring MVC and Jersey MVC now works.

[stephen]

Personally, I think "blessing" UI frameworks as JSRs ("official!") is a bad idea.

I think it leads to the UI framework (e.g. JSF in the past or this new MVC spec) "winning" and getting adopted by teams who, if they had to evaluate several competing non-blessed frameworks, would pick something better/easier/more modern, but instead go with the JSR-backed option.

Although perhaps I'm just being pessimistic. JSRs can probably be a good thing; as a programmer in the JVM ecosystem, I've just never considered "it's a JSR" as a brand of quality/something that should affect my choice, and if anything it's the opposite.

(My pessimism aside, if they're basing the spec on existing good ideas, like JPA did for Hibernate, and JSR-310 did for Joda time, that is at least a smart approach.)

[eranation]

This is great news!

[mkawia]

Working with Java Servlet is very hard to be productive in it , Simple things that I took for granted like routing,templating,user management and processing forms with binaries ie form-data is really hard.

But the static typing is really good ,ofcourse the language too .Maybe I should I've tried Jersey .

[eranation]

Yes, servlets are not the best for modern web development :) (although they have their uses...) JAX-RS (jersey is the reference implementation) is like a parallel universe, well designed, batteries included, statically typed REST API framewrok that has a lot of potential (I prefer it over Spring MVC in terms of syntax or even over play framework's routing)

[spacemanmatt]

If I had to go back to Servlet development today, I would probably go directly for Spring WebMVC or whatever is current from Spring. I also wasn't a big fan of the Servlet system.

[eranation]

I second that. If you really want to save time start with spring boot, or even a yeoman generator like JHipster...

[john-waterwood]

There's very little need to go to Spring today. Base Java EE includes nearly everything that one needs.

Plain Servlets is what you get when using just Tomcat, but Java EE goes beyond that with really great support for bean management and DI (CDI), persistence via ORM (JPA), declarative validation (bean validation), REST (JAX-RS), MVC web franework (JSF), etc

[StevePerkins]

Oh, I couldn't possibly disagree more.

JEE has come a long way, and it's a shame that people unfairly dismiss it today due to their ancient experiences with EJB 2.x. However, JEE is a very conservative stack, which suffers greatly from "design-by-committee". Spring therefore is, was, and always will be at least a generation or two ahead.

JEE requires an old-school big honking app server such as WebLogic or JBoss. Lighter-weight alternatives such as TomEE are only just now starting to become suitable for production use. Because the JEE model is to have a slew of libraries loaded at the global app server level, you're much more likely to run into conflicts with libraries that your application loads at its WAR/EAR file level. Moreover, "standards" notwithstading... you do get locked in to your particular app server, and will experience breakage when migrating to a different vendor who bundles different libraries implementing those standards.

With modern Spring Boot, everything you need gets bundled into a self-contained and safe archive file. Moreover, it doesn't even have to be a WAR. You can easly bundle a production-grade embedded Tomcat instance (or Jetty or Undertow) directly within your application, building an executable JAR file with no dependencies whatsoever apart from having a JRE installed on the target machine. Putting an app server inside your JAR might sound inefficient at first, but it's a devops dream and is ideally suited for today's trend toward microservice architecture. These days disk storage is a lot cheaper than unnecessary system complexity. Besides, a typical app with Spring and Tomcat bundled is STILL a fraction of TomEE's size.

Spring's dependency injection is straightforward, and compatible with other JSR-330 implementations like Guice and Dagger. I find JEE's CDI to be a clunky mess in contrast. In the presentation tier, Spring these days steers developers toward Thymeleaf templates, which are consistent in usage with most of the modern JavaScript frameworks they are likely using already. JEE steers developers toward JSF, which even in its modern form tries to simulate concepts from .NET WebForms (Microsoft has meanwhile walked away from this as outdated bad practice).

Last but not least, there is community engagement to consider. If you take a Spring problem to StackOverflow, you will have an answer within minutes. Hell, you could even take it to IRC and probably get answers in real-time. By comparison, the JEE "community" is practically non-existent... and if anything consists mostly of consultants seeking to sell you their time.

Again, JEE has indeed come light years from where it was a decade ago. But because of its conservative, committee-based DNA... it will always be years behind Spring, and delivering solutions much more muddy and disjointed. Spring seems to occupy an ideal common-sense spot on the spectrum. It lags several years behind the "hipster" frameworks of other platforms, stealing at a stable and production-grade pace those innovations that prove themselves. At the same time, it's well ahead of the glacial pace at which those innovations make their way (poorly) into the Oracle-blessed standards.

[henk53]

>Spring therefore is, was, and always will be at least a generation or two ahead.

It should indeed be the idea that Java EE is behind. Its stated purpose is to standardize that what has been proven to work. It doesn't aim to be highly innovative. Instead, it aims to be a stable base on which other technologies can build without having to be afraid that the platform changes underneath them every few months, and without much fear that the platform suddenly changes directions radically.

Keeping that in mind it's funny that CDI is so much more innovative, modern and powerful when compared to Spring Beans. CDI (and by extension Java EE) engaged in the no-XML revolution when Spring was still trying to put MORE code into their proprietary XML format. I've seen Spring applications that were ~50k lines of Java code and ~150k of Spring XML code. Gives a whole other meaning to the term XML hell.

And let's not start about the -contextual- injections and the powerful extension mechanism that CDI pioneered well before Spring was even thinking about such things.

Here Spring is at least 2 generations behind Java EE. And before you start about it, no, CDI was not inspired by Spring. Guice and both JSF native beans and EJB were CDI's inspirations.

>JEE requires an old-school big honking app server such as WebLogic or JBoss. Lighter-weight alternatives such as TomEE are only just now starting to become suitable for production use.

JBoss is NOT old-school and big honking (whatever that means). The download size of JBoss is about 110MB, and it starts in about a second. 10 seconds with an app that contains hundreds to thousands of beans.

Compare that to a typical Spring app, where the downloaded size of all things you need easily exceeds 200MB and the war itself is a 100MB or so. A war for Java EE is often some 1 to 2MB for a BIG application. Go figure.

A Spring app with so many beans takes up a minute to boot, at least. Granted, I last checked about 2 years ago, maybe it's better now.

TomEE has been viable to be used for quite some time, and next to TomEE there's also Resin and Liberty web profile which are about as small (some 30MB).

>Moreover, "standards" notwithstading... you do get locked in to your particular app server, and will experience breakage when migrating to a different vendor who bundles different libraries implementing those standards.

You may get small breakages, but you at least have a chance to migrate!

Imagine migrating your 500k loc application from Spring to Play. Not going to happen. With Java EE I've migrated applications between all major servers. Sure, there were small things breaking, but on average it took me and the team about 2 weeks to fix. 2 weeks is NOTHING compared to a total migration to another platform which can take years.

>With modern Spring Boot, everything you need gets bundled into a self-contained and safe archive file.

This is only a fairly recent development for Spring, and Java EE vendors have solutions here as well. TomEE has been capable of doing this for years, and recently there have been solutions for GlassFish (http://www.payara.co.uk/introducing_payara_micro) and JBoss (http://wildfly.org/news/2015/05/05/WildFly-Swarm-Released/)

>Putting an app server inside your JAR might sound inefficient at first, but it's a devops dream and is ideally suited for today's trend toward microservice architecture.

From the very article this HN post links to, that startup is doing something like that already with Java EE.

>Besides, a typical app with Spring and Tomcat bundled is STILL a fraction of TomEE's size.

Yeah, sure. See my comment above. TomEE is some 35 MB and contains nearly everything you need. Try adding Spring libs and all their dependencies, as well as Hibernate and a transaction manager to your war. That 35MB gets eaten away pretty quickly. And please don't think that just because you only put dependencies in the pom.xml file that the data is not really there. Take a look at the final war that's build. This is often way larger than 35MB when Spring is used.

>I find JEE's CDI to be a clunky mess in contrast

I think it's exactly the other way around...

>Spring these days steers developers toward Thymeleaf templates, which are consistent in usage with most of the modern JavaScript frameworks they are likely using already. JEE steers developers toward JSF, which even in its modern form tries to simulate concepts from .NET WebForms

Thymeleaf unfortunately is not very memory efficient compared to JSF's Facelets. See http://www.jsfcentral.com/articles/understanding_jsf_perform...

And Facelets/JSF uses modern templating based on plain HTML these days.

>Microsoft has meanwhile walked away from this as outdated bad practice)

No, Microsoft walked away since they had never been able to put the effort in to create a next gen version of their platform. In JSF terms WebForms is still at JSF 1.1/1.2.

ASP.NET WebForms never had its JSF 2.0 release, and it doesn't have things like PrimeFaces and OmniFaces.

PrimeFaces DID try to make a component set for WebForms, but gave up because the underlying technology was just too outdated.

>If you take a Spring problem to StackOverflow, you will have an answer within minutes.

Uhm, you can't be serious here, are you?

Ever heard of BalusC?

The JSF community is HUGE on stackoverflow, things are answered pretty quickly and there are about twice as many questions (and answers!) there compared to Spring MVC.

>By comparison, the JEE "community" is practically non-existent...

On the contrary, it's really big. Every sub spec has a public JIRA where anyone can submit ideas and looking at the last release indeed many ideas have been implemented that were proposed by the community.

I think you have 2003/2004 in mind and never looked back. Things have changed drastically since then.

[StevePerkins]

> JBoss is NOT old-school and big honking (whatever that

> means). The download size of JBoss is about 110MB, and it

> starts in about a second. 10 seconds with an app that

> contains hundreds to thousands of beans.

>

> Compare that to a typical Spring app, where the downloaded

> size of all things you need easily exceeds 200MB and the war

> itself is a 100MB or so. A war for Java EE is often some 1 to

> 2MB for a BIG application. Go figure.

I tried to steer clear of precise numbers, because they tend to change every couple of years... and you can easily date your knowledge by citing them.

However, spin up a new Spring application today (there's an online project generator wizard at http://start.spring.io). Make it a web app, with Hibernate/JPA and the PostgreSQL database driver, and Spring Actuator for automated metrics. Build this generated app. The resulting executable JAR with all dependencies will weigh 24 megs, and that includes its app server.

Ditch the Hibernate/JPA, and use PostgreSQL with Spring JDBC instead (which is often superior to an ORM anyway). Your total deliverable size drops to 13 megs.

Look, it's all Java at the end of the day. Spring plays nice with JEE components, and in practice it's not necessarily such an either/or matter. The Java community has a sliding spectrum of bleeding-edge early adopters (e.g. Scala, Akka, Play)... conservative late-adopters (e.g. JEE)... and pragmatic moderates in between (e.g. Spring). If your comfort zone is on a different spot in the spectrum, or if you disagree with how someone else defines the spectrum, then by all means do your own thing. But the comment to which I replied said that, "There's very little reason to use Spring today". That, frankly, is nonsense.

[superchief]

Sheet, are you really seriuous? I totally disagree with your comments. Spring is always miles ahead of java ee. Java ee copies spring inventions. For me it has been a long road to migrate away from "java ee hell". The less java ee the better and more productive to code. Nobody uses xml nowadays, its called java configuration. And who cares about the final jar/war size ?