
Spring vs. Java EE - root_node
https://gist.github.com/philwebb/b0ebfd4fc7c5c519d82361b8e9744fa4
======
dlandis
Personally, I haven't heard anything about renewed debates related to Spring
vs. JEE in many years. And if you read the Gartner report in question[1], it's
not about that at all. Hmm. Maybe I'm just cynical, but when I saw he was part
of the company behind Spring I thought maybe this was more of a contrived
argument. The truth is, framing a debate as Spring vs JEE perhaps stands to
benefit both technologies since in many people's minds they are both complex
and bloated. It's just about positioning; yes, Spring is "lightweight"
compared to traditional JEE, but so is everything!

1\.
[https://www.gartner.com/doc/reprints?id=1-3N8E378&ct=161205&...](https://www.gartner.com/doc/reprints?id=1-3N8E378&ct=161205&st=sb)

~~~
stickfigure
_" lightweight" compared to traditional JEE, but so is everything!_

This isn't going to make me popular on HN but: I don't think this is actually
the case.

Back in the mid 2000s I built EJB services by defining simple interface and
implementation classes. I consumed the service by by injecting the interface
into my clients. I tested my consumers by mocking the interface.

Now I build REST services. I have to define and document a complex dance of
verbs, nouns, and payloads. Client code requires stitching together text
fragments into URLs and JSON. There's no typechecking across API boundaries
and testing requires me to stub out crappy HTTP libraries.

Hmmmm.

There are good things to say about REST (like transparency and ubiquity), but
it's not totally clear to me that the world is better off now than we were
back in those Dark Days. Yeah, there was a lot of _awful_ EJB code, but I'm
finding no shortage of shitty REST microservice code floating about nowadays.

~~~
16bytes
The way I remember it is if you were single-stack from client to server, yeah,
EJBs and others in the J2EE worked pretty well.

On the other hand, if you wanted to get of the rails and have clients in
multiple stacks and clients who talked to different stacks, then it just all
fell apart. Even multiple vendors in the J2EE space could be a problem.

Being able to do things simply hid a lot of complexity. It was hard to
investigate that complexity when things went wrong.

It feels like chaos today, with myriad front-end frameworks and best practices
changing every three months, but I would take this over mid-2000's Java tech
because it just simply seems like less magic. I can break out Postman and just
see what's going on.

I agree that there's no golden bullet, and that there's no end of crappy REST
definitions. Furthermore, it's mostly not even REST, not in a HATEOAS kind of
way.

But that's ok, I still feel more productive than I did 15 years ago, and I
wouldn't want to go back.

------
openasocket
I like Java, but I've never tried diving into the Spring or Java EE world. The
little I've looked at it seem daunting and complex and I'm not sure what it
really gives you at the end of the day. What functionality does it provide,
what are the killer features? And is all this complexity justified?

~~~
jacques_chester
I'll put my disclosure up-front: I work for Pivotal on a Cloud Foundry
project. Pivotal employs many members of the Spring team. I am not speaking
for either Spring or Pivotal.

Both Spring and Java EE are very featuresome because of a long period of
evolution across multiple partial paradigm shifts (3-tier, CORBA, Web 1.0, App
Containers, SOA, VMs, Web 2.0, Containers...).

I'm personally only familiar with Spring. And by "familiar" I mean I've learnt
enough to be dangerous. But I've also learned to ask, before doing something:
"Have the Spring team already solved this?"

Take, for example, retrying an operation. A slightly hacky way to achieve this
is to nest try-catches. A slightly less hacky way is some sort of loop. Then
we extract this functionality out. I dunno, lambdas maybe?

Or: I could use Spring-Retry[0].

That's just one example from my own experience.

It used to be that Java EE was _it_. And it _had_ to be: the mega-buyers
insisted that there were sufficiently rigorous standards that they could
switch vendors. Every giant corporation bleeds gold to some ancient vendor and
they have an immune reaction, nearly a spasm allergy, to vendor lockin[1].

Opensource tools kinda sail around this, because ... uh ... _what_ vendor
lockin? Who has you grasped, by what kind of delicate hair? Nobody. It's
opensource. You can wait for community action, or engage a consultancy, or a
related product company, or hire specialists, or sponsor something ... you
have a wider range of options.

Oh sure, there's _tech_ lockin, but that's true of any decision. Either you
exploit the features of a platform and tie yourself to it, or you write a
rubber-room abstraction layer and tie yourself to _that_ instead, but at your
expense.

In my observation as a 1st? 2nd? party, the Spring team pay close attention to
the standards and support them. And, not coincidentally, many standards look
-- gee, just _awfully_ similar to something Spring had road-tested a few years
prior.

I think a lot of the shade thrown in this debate is happening because of
_money_. Pivotal backs Spring very strongly, because it helps to sell our
version of Cloud Foundry (imaginatively: Pivotal Cloud Foundry).

Meanwhile, Oracle owns a lot of Java products, some inherited from Sun, as
well as being the stewards of the Java EE standards process. Red Hat own a
solid suite of Java EE-capable and platform products, a portfolio largely
overlapping with Pivotal's, IBM's and SAP's.

In each of these cases there's a zero-ish sum-ish game underway. A company
that bets on Red Hat doesn't bet on IBM. A company going all-in with Oracle
(RIP your chequebook) isn't going to buy much from Pivotal.

Meanwhile, the Spring team are just writing software. I lurk some of their
internal Slack channels. It's almost exclusively technical and usually very
thoughtful. As a Pivot indoctrinated by Pivotal Labs, I appreciate having a
very different example of how to develop high-quality software.

[0] [https://github.com/spring-projects/spring-
retry](https://github.com/spring-projects/spring-retry)

[1] You will often find companies accusing each other this.

~~~
twic
> Or: I could use Spring-Retry[0].

The idea that you would add a dependency to avoid writing a try-catch in a
loop is absolutely bewildering to me. What next, Spring Pad? I can see it now:

    
    
      @LeftPad(width = 50)
      public String getNameForDisplay() {
        return name;
      }

~~~
nimish
Being able to quickly change in different retry mechanisms and policies is
pretty useful. Sometimes you want exponential backoff, sometimes no backoff,
sometimes it depends on other state.

Not as simple as you might think. And if you're gonna be writing microservices
you're going to be intimately familiar with retries.

~~~
wsargent
I really like jhalterman's failsafe library. Exponential backoff, jitter,
circuit breaker support, etc.

[https://github.com/jhalterman/failsafe](https://github.com/jhalterman/failsafe)

------
folli
If I want to build a web app from scratch which should have some basic
features (user identification, some standard level of security, REST
interface, database integration) and I have some okay knowledge of Java
(mainly CLI applications and some Android programming), which framework would
you recommend for me to get started? I'm afraid to get lost in the details too
quickly, so a framework that provides a working example which can than be
adjusted to my needs would be very welcome. Any suggestions?

~~~
manyxcxi
Dropwizard and Play are very good alternatives to Spring if you don't need the
whole kitchen sink or you absolutely want to use X library for Y application
function and Spring doesn't necessarily have very good out of the box support
for said library.

The upside of Spring over Dropwizard or Play (or any of the lighter touch
frameworks) is that it's so much more than an MVC or REST controller
framework. The report in question is literally comparing it against the entire
Java EE ecosystem. Spring is not a library or a framework anymore, it's
practically an entire stack that you can pick and choose from.

Play and DW are likely to be easier to get your head around than Spring,
there's a lot of magic going on in there and (not unlike getting into the JS
world these days) you will find that setting the thing up from scratch takes a
whole lot more time than you ever would have guessed. There's 1000 ways to do
the same thing and sometimes doing it one way is a real issue later on, and
worst of all it may not be apparent that that is the root source of some
seemingly unrelated issue.

Spring Boot aims to solve a lot of that by taking an opinionated approach to
how the project should be laid out, libraries, and default configuarations-
more along the lines of a .NET MVC + database, etc. There's still the same
amount of complexity and configuration, it's just hidden from you until you
need to dig in.

I generally use Spring Boot to start greenfield projects these days, we deploy
to AWS and their extra libraries for handling and working with that save a lot
of boilerplate that's so common with Java.

I would suggest you get your feet wet with either GP or DW, but don't forget
about Spring Boot down the road. I've gotten to the point where I've got a
stack including Vault (secrets) + Spring Config Server (distributed config
application) + a fleet of various Spring Boot microservices running in Docker
on AWS and they (mostly) just startup and run the way I wanted them to. It's
really awesome, and wildly overkill for that proof of concept API or personal
project we would be doing a lot of, but allows me to run my company without a
huge team.

~~~
wsargent
Hi, I'm on the Play team. We've got a number of Play maintained example
projects that show how you can configure different projects:

[https://playframework.com/download#examples](https://playframework.com/download#examples)

Should save you some time if you're looking to get started with JPA, different
libraries, etc.

Also, this doesn't really get at the strengths of Play as a reactive
application. For example, here's a talk where I discuss using Reactive Streams
with Play to stream video through Play. It's about two years old now:

[https://www.youtube.com/watch?v=zUB7GJMe_WY](https://www.youtube.com/watch?v=zUB7GJMe_WY)

Thanks!

------
twblalock
In terms of the popularity of the two frameworks, all I can say is that I have
been interviewing 2-3 Java engineers per week for the past few months, and
almost all of them put Spring on their resume and not Java EE.

~~~
EtienneK
This does seem to be the trend the industry is taking. And for good reason.

After using Spring Boot for 2 years now, I'll never go back to EE.

------
neverminder
> for example here’s a copy from Lightbend (the company behind Scala, Play &
> Lagom)

I use Play 2 for most of my projects and frankly knowing what I know about
Spring and J2EE (even though having never worked with them for the same
reason) I couldn't really think of any reason to choose either of these
outdated behemoths. With something like Play 2 and Slick/JOOQ you could run
circles around these two.

~~~
gbersac
Same here, Scala rocks ! Too bad play 2 is now using guice and promots runtime
dependency injection like in Java world. Compile dependency injection is much
better, I fear they'll try to mimick spring more and more in order to attract
java crowds.

~~~
raphaelj
I got the same feeling here. Implicits in Scala can act as statically checked
dependency injection, I don't know why they are going for this runtime
dependant injection instead.

~~~
merb
Play supports static DI aka cake pattern or macwire aswell.

------
sgt
I am gradually phasing out Java EE in favor of vertx.io

~~~
springsux
I don't get reactive or functional. I get, step 1 do something, step 2 if
something then do step 4 else step 3. Those were really the days. I guess if I
could have my dream framework today it would be just Java and some Apache jars
and some Google jars, maybe an odd jar here or there. And Eclipse, always
Eclipse.

I'd also steer clear of anyone who can quote GoF or Fowler.

------
codecamper
I'm surprised this is still a thing.

------
marktangotango
Spring and EJB 3 are like Django, Rails, and their ilk: big bloated frameworks
that include everything you need to build multi tier apps, plus or minus a few
features here and there. Convergent evolution is a wondrous thing.

~~~
specialist
Feels more like enterprise architecture jargon bingo.

I never understood (the point of) EJB. Shamefacedly admit I was once a huge
Hibernate fan. But I got over it.

Can't speak to Django nor Rails.

\---

Prior joke: Spring is an stacktrace obfuscation framework.

New joke: NodeJS is a control-flow obfuscation framework.

~~~
spiralpolitik
The original goal of EJB's was to push functional decomposition out onto the
network.

Entity beans were always a disaster, and Stateful Session Beans had scaling
problems, but Stateless Session beans by the time of EJB3 were an easy way to
push logic out to the network while getting a whole bunch of stuff (pooling,
scaling, failover, transaction management, security, etc) for free.

These days they'd be calling them micro services.

The main problem was combining everything into the big ball of mud that is
J2EE. If they had let each component live and die on its own merits I think
the ecosystem would be in a much better state today.

------
scaleout1
Spring vs. JavaEE is a topic that stopped being relevant five years ago. I
cant believe anyone seriously considering any of these heavy duty teach stack
in 2017. There are much much better choices out there even for Java
developers, and if they can come out of their comfort zone a bit there is
Clojure, Scala, Kotlin etc with MUCH nicer fraemworks

~~~
jrwiegand
What frameworks would you recommend or look to get started with?

~~~
yogthos
Try Luminus [http://www.luminusweb.net/docs](http://www.luminusweb.net/docs)
for Clojure. It's pretty easy to get started with.

