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.
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
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.
>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.
>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
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.
> 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.
>There's very little reason to use Spring today". That, frankly, is nonsense.
We all have our own preferences. I can guess what the "very little reason means". You hear this more often in Java (EE) discussions.
The thing is that in 2003/2004 Spring positioned itself as the necessary layer to make arcane Java EE APIs approachable and usable. With their FooBarTemplates Spring wraps everything that's wrappable, and at the time it made somewhat sense. Rod couldn't wrap EJB though, and as he deemed it "unfixable" he invented his own bean model to replace that.
At some point though Java EE started improving, and then started to improve a lot. Getting first class APIs such as JPA, co-designed by the Hibernate lead himself (Gavin King).
And what did Spring do? As a pavlov reaction they started wrapping again. But the JPA APIs were brand new, perfectly well designed, and didn't need wrapping. This was the basis of the fallout between Hibernate and Spring, and a revealing moment into how Spring operated. They weren't the benevolent dictator who out of the goodness of their hearts wanted to make life better for programmers, no, they just wanted you to depend on their APIs.
Rod later cashed big time, and Springsource, later pivotal became as commercial as the "evil" corporations they tried to wrap with their APIs.
Fast forward to Java EE 7, and Java EE has tons of perfectly fine APIs that don't need the Spring wrapping treatment. JMS, JPA, Bean Validation, CDI, EL, JAX-RS, ... NOTHING of that needs wrapping by Spring to make it usable. It's perfectly fine as-is.
So this is where the often heard "there's little reason to use Spring today" comes from, and I guess that is what was meant. Today Spring is just another platform. Java EE programmers don't need it to make their life better. Programmers in general can choose Java EE, or Spring, or .NET, or whatever.
If your preference is Spring, please, use it and be happy. It's not better than Java EE, but likely not much worse either. I've seen enough Spring code and Java EE code to say it's different, but still fairly equal.
I personally think the design process of Java EE is more open than that of Spring. Both are open source projects, and both have strong commercial influences as well as community influences, but with Java EE the design process is fully out in the open and people can comment on it and contribute. This is less the case with Spring. Yes, the source is open, but so is that of the Java EE RI and many other implementations. But Spring doesn't have an open design process, where Java EE has.
> JMS, JPA, Bean Validation, CDI, EL, JAX-RS, ... NOTHING of that needs wrapping by Spring to make it usable. It's perfectly fine as-is.
LOL, JMS. I take it you never actually used JMS. Where should I start? Ah yes, checked exceptions. JMS (of course) doesn't support Java 1.5, the API still uses raw types. Also JMS (of course) doesn't even support Java 1.4. You see JMS predates Throwable#getCause so JMSException#getCause is undefined and you have to use JMSException#getLinkedException. In addition the only way to wait on a Queue without blocking or polling is to use an MDB but there is no (!) standardized way to associate a RAR with an MDB. On top of that JMS is six APIs in one. There is the part old API that you're only allowed to use in Java EE, there is the part of the old API that you're only allowed to use in Java SE and then there a part of the old API that you're allowed to use in Java SE and Java EE. How do you know which methods fall into which category? Since Java EE 7 it's a comment in the Javadoc, otherwise you have to be familiar with the spec (yes, it is on a per-method basis, not an a per-interface basis). Then there is the new API (JMSContext) which follows the same "pattern" but uses runtime exceptions for certain parts until you're at the point where it uses checked exceptions again.
Yes, JMS, perfectly fine as-is and doesn't need wrapping to make it usable.
> But Spring doesn't have an open design process, where Java EE has.
I take it you're not actually a JCP member and tried to get a feature into a JSR? It you were you wouldn't make statements like this. Java EE is open only by name.
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 ?
So home come Java EE started with no-XML and annotations way before Spring?
>Java ee copies spring inventions.
So why did Spring years later also went the no-XML route and started with annotations?
>Nobody uses xml nowadays,
Because Java EE adopted the move away from XML early. When all major frameworks where moving away from XML, Rod was still trying to let you write MORE XML.
>And who cares about the final jar/war size ?
The Spring guys cared about the size of the combined total when Java EE was still bigger. I can't count the times that Rod ridiculed Java EE about this.
Now Java EE is slimmer and now it suddenly doesn't matter? Funny...