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

21–30 of 119 posts

Re: Spring vs. Java EE

#21

Post by specialist »

marktangotango wrote: post #17

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.

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.

Re: Spring vs. Java EE

#22

Post by orless »

vbezhenar wrote: post #16
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?

Both Java EE and Spring provide a huge amount of functionality and do it in an uniform way, so you don't have to glue lots of different libraries together. They aim for enterprise world, where this functionality is required. Not every project need it, so sometimes it might be not necessary. IoC is awesome on huge projects, but if your project is 10-20 classes, it's just unnecessary abstraction. Distributed transactio…

Whether IoC is reasonable or not does not depend on the number of classes in the project. It is still a useful pattern even if you have, like, 3 classes (component A using implementation B of the interface Ib). It's just if you have only few components, you may want to wire them manually in maybe 10 lines of code instead of dropping in Spring JARs.

Re: Spring vs. Java EE

#23

Post by ivan_gammel »

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]:…

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.

Re: Spring vs. Java EE

#24

Post by ivan_gammel »

orless wrote: post #19
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…

"... so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool." It is the failure of concepts so if the tool brings the right concepts, it helps avoid such design mistakes in the first place.

That's too generic statement to be applied to anything. Some specific failures of tools (what exactly?) may be the cause of other issues, but it's not the law of nature. You can hit your finger by a hummer, but it's not because hummer brought the wrong concepts - it served millions of people to build their homes, their farms and fences, it's just because sometimes you miss the nail.

Re: Spring vs. Java EE

#25

Post by orless »

ivan_gammel wrote: post #24
orless wrote: post #19

Earlier quoted context omitted.

"... so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool." It is the failure of concepts so if the tool brings the right concepts, it helps avoid such design mistakes in the first place.

That's too generic statement to be applied to anything. Some specific failures of tools (what exactly?) may be the cause of other issues, but it's not the law of nature. You can hit your finger by a hummer, but it's not because hummer brought the wrong concepts - it served millions of people to build their homes, their farms and fences, it's just because sometimes you miss the nail.

It is only generic if you completely drop the context of the discussion (Spring and dependency injection). My point is that Spring brings DI/IoC concepts which help build healthy projects.

Re: Spring vs. Java EE

#26

Post by cle »

ivan_gammel wrote: post #8
cle wrote: post #5

Earlier quoted context omitted.

The Spring that I've used (the DI Framework, Spring Integration, Spring MVC) is mainly designed to simplify and standardize enterprise applications. Mostly this involves standard and automated ways to "wire" together applications. This includes DI, but also includes configuration (e.g. configuration to enable a deployment pipeline), communication between components/services (client and server mapping of messages in a…

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…

It enables such designs, by making it easy for someone to add more crap into your ball of mud. Not everyone on your team is as smart or experienced as you. When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring!

Well, you care when you have an unexpected complex circular dependency or you need to refactor and you suddenly discover how complex your dependency graph has unintentionally become.

By "decoupling" and "modularization", I'm not talking about at a code-level by using interfaces. In my opinion, that kind of decoupling and modularization isn't very important, especially when it comes to application glue--because the glue (Spring) is what decides the backing impl's of all those interfaces. That's where the important dependencies lie, and that's where your big ball of mud accretes.

Re: Spring vs. Java EE

#27

Post by 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.

Re: Spring vs. Java EE

#28

Post by snambi »

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 used to like spring in favor of JEE Application servers. But of late, spring is getting too bloated, too complicated and buggy. OTOH, newer java frameworks are simpler and easier to work with. For example, spark application framework or retrofit for rest APIs. At this point spring is very similar to JEE.

Re: Spring vs. Java EE

#29

Post by gbersac »

neverminder wrote: post #27

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

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.

Re: Spring vs. Java EE

#30

Post by edem »

gbersac wrote: post #29
neverminder wrote: post #27

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

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.

Until you start working with Clojure or even Kotlin. Then Scala feels like a baroque behemoth.
Post reply on HN