Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Spring vs. Java EE

gist.github.com

Post reply on HN
Print view View original

61–70 of 119 posts

Re: Spring vs. Java EE

#61

Post by sandGorgon »

folli wrote: post #34

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 exa…

Since ur not tied to the Java language (but want the power of the JVM platform) - I would say vert.x with kotlin.

Re: Spring vs. Java EE

#62

Post by privacyfornow »

folli wrote: post #34

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 exa…

My recommendation is Vertx.io

It is a very lightweight framework with support for most of the plumbing a developer might want without imposing its will on anyone.

If you are not that worried about having a REST or HTTP or TCP front-end, LMAX disruptor is amazing as well.

Re: Spring vs. Java EE

#63

Post by nimish »

twic wrote: post #56
jacques_chester wrote: post #10

Earlier quoted context omitted.

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. An…

> 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; }

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.

Re: Spring vs. Java EE

#64

Post by johndubchak »

manyxcxi wrote: post #45
edem wrote: post #33

Earlier quoted context omitted.

You call Spring an outdated behemoth yet you have never worked with it. I've worked with EJB, Spring, Play, Dropwizard and a bunch of other stuff an I can tell that the current version of Spring is cutting edge and since they introduced java-based configuration you can really do stuff with it without the hassle which comes with other frameworks. Make yourself a favour and don't make a fool of yourself by bashing some…

I can't agree enough. I can't find anything else with support that the Spring ecosystem has built for many cloud stacks (my experience is with AWS). Being able to choose from a whole host have identity providers, social, and other things for login and user data that generally just fits in to the normal auth and security mechanisms solves a problem we had for years with new applications. It's certainly daunting if you…

I work with Spring everyday and really appreciate how it simplifies many things with enterprise Java development. However that appreciation has come with a cost.

In the original "Java Development with the Spring Framework" in 2005, it was argued that J2EE was far too complex in order to be effective. Spring was going to provide a simplifying framework to make development easier.

To me it's ironic how Spring has evolved in complexity over the years, but it's the first framework any of us turn to.

Re: Spring vs. Java EE

#65

Post by EdwardDiego »

twic wrote: post #50
jacques_chester wrote: post #32

Earlier quoted context omitted.

I disagree. Constructor injection in Spring is more test-friendly; in turn that tends to allow us the liberty of more aggressively modularising the design. With other injection types either more bookkeeping is required to cleanly set up tests; or alternatively, "unit" testing becomes more integration-esque. It's a second-order effect felt in the many small decisions that lead one to the mudpit. That's why I used the…

> Constructor injection in Spring is more test-friendly If you get in the habit of using the Spring test support, where classes under test get injected, then all kinds of injection are equally friendly, and the tests don't give you feedback on the weight of the dependencies because Spring does the heavy lifting. And, in my experience, where you do inject dependencies by hand, the design pressure is actually towards c…

> If you get in the habit of using the Spring test support, where classes under test get injected, then all kinds of injection are equally friendly, and the tests don't give you feedback on the weight of the dependencies because Spring does the heavy lifting.

How do you handle the Spring context start-up time? In Spring projects I've worked on, across hundreds of unit tests it's non-trivial. But I don't make any claim to know if we were doing Spring right or not.

Re: Spring vs. Java EE

#66

Post by EdwardDiego »

jacques_chester wrote: post #32
ivan_gammel wrote: post #23

Earlier quoted context omitted.

Nope. There is no difference between injection types from the coupling perspective, simply because neither blocks anything bad from happening in your architecture. There are reasons to prefer constructor injection in many cases, but it has nothing to do with modularity or coupling.

I disagree. Constructor injection in Spring is more test-friendly; in turn that tends to allow us the liberty of more aggressively modularising the design. With other injection types either more bookkeeping is required to cleanly set up tests; or alternatively, "unit" testing becomes more integration-esque. It's a second-order effect felt in the many small decisions that lead one to the mudpit. That's why I used the…

> Constructor injection in Spring is more test-friendly

These are my thoughts too. No reflection or @MoreAnnotations to inject dependencies. I have an aversion to setter/field based injection because it allows you to instantiate an object in an incorrect state.

Re: Spring vs. Java EE

#67

Post by edem »

scaleout1 wrote: post #43

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

Name just one alternative you have in-depth experience with. Not just pet projects but production code.

Re: Spring vs. Java EE

#68

Post by baylisscg »

orless wrote: post #13
openasocket wrote: post #2

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?

I work with Spring and Java EE professionally, prefer Spring wherever I can. Also use Spring for private/side projects (if not plain Java). But I'll talk about Spring here. I see two import aspects that Spring provide: first, dependency injection/inversion of control as basis and then a way to 1000+1 things "right". Dependency injection is important because it provides a healthy way to compose an application from man…

I'd add a few more caveats.

- Not all Spring projects seem to receive equal love. They can and do stomp on each other. - Spring's get-going-quickly seems to mostly come from serious design assumptions. Which is fine per se but they are not made clear which is not OK. - Spring is far too automagical. My latest bugbear is it deciding to change defaults depending on what it thinks I want. Bonus points for there being multiple settings that control the same behaviour only one of which can override.

You're not using Java anymore you're using Spring.

Re: Spring vs. Java EE

#69

Post by tigershark »

jacques_chester wrote: post #11
ivan_gammel wrote: post #8

Earlier quoted context omitted.

Spring (and latest JEE editions with better support of DI) no more encourages spaghetti designs than does manual wiring of objects, so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool. In fact, properly designed system that uses DI is indeed decoupled (because you can limit the number of interfaces between components) and modularized (because you c…

I think maybe this comes down to the kind of injection. If you rely on variable or setter injection, you can easily create a kind of dark matter that invisibly warps the flexibility of the project. I and others have generally found that using Constructor injection greatly decouples a design and simplifies testing. And the Spring team have been saying so for at least as long as I've paid attention to the question[0]:…

They are two different tools needed for two different jobs. Constructor injection is for mandatory dependencies, setter injection is for optional dependencies. If you are writing a plugin application and some modules are optional then you cannot use constructor injection because when the optional module is not present you cannot start your whole application. In 99% of the cases obviously constructor injection is the way to go.

Re: Spring vs. Java EE

#70

Post by stickfigure »

dlandis wrote: post #9

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…

"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.

Post reply on HN