Live data from Hacker News

Spring vs. Java EE

gist.github.com

111–119 of 119 posts

Re: Spring vs. Java EE

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

Have you ever made anything real with Vert.x? I found several aspects of developing for it problematic, such as it's rather odd module sysem.

Re: Spring vs. Java EE

#112
post #108

Earlier quoted context omitted.

There are so many counter-examples in the world of poorly built projects, that I don't really understand how did you came to this conclusion. DI/IoC is just a pattern, there's no way it could guide you to good architecture itself. Spring is just a tool, which adds some constraints, but which does not force you to make business decisions on scope of different domains or interaction between them that might lead to stro…

I'm not sure where I stated that Spring forces "to make business decisions on scope of different domains or interaction between them that might lead to strong coupling and low modularity".

Let me explain in other words. You said: >It is the failure of concepts so if the tool brings the right concepts, it helps avoid such design mistakes in the first place. In the context of Spring/DI it does not make sense, because no matter what, some developers do and will be doing design mistakes related to coupling and modularity and some will write great code, but this is neither feature nor failure of the tool. DI/IoC is too low-level concept to influence application design, because in case of Spring it affects individual classes, not components, namespaces or subsystems. It is the responsibility of the developer to make decisions and create designs that make application modular, designs that restrict number of dependencies etc, and, in general, to do all the work required to avoid creating "giant ball of mud". The result of this work done with Spring or any other IoC/DI framework will not be very different from manual instantiation of objects and wiring.

Re: Spring vs. Java EE

#113
post #29

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

Hi, I'm on the Play team. We've got a number of projects showing compile time injection:

Java compile time DI:

https://github.com/playframework/play-java-compile-di-exampl...

Java compile time DI using Dagger 2:

https://github.com/playframework/play-java-dagger2-example

Scala compile time DI:

https://github.com/playframework/play-scala-compile-di-examp...

Scala compile time DI with Macwire:

https://github.com/playframework/play-scala-macwire-di-examp...

Thanks!

Re: Spring vs. Java EE

#114
post #63
post #56

Earlier quoted context omitted.

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

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

https://github.com/jhalterman/failsafe

Re: Spring vs. Java EE

#115
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…

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…

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

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

Thanks!

Re: Spring vs. Java EE

#116
post #50

Earlier quoted context omitted.

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

The context can be reused between tests. If you're not storing data in beans (which you normally shouldn't), this works well. There is a bit of subtlety in that the framework might have to create multiple context for different configurations, but each of them is reusable.

Running a single test is a bit of pain, but running the whole suite is not a lot slower than if it didn't use Spring.

Re: Spring vs. Java EE

#117
post #49

Earlier quoted context omitted.

If you want to see big balls of mud created using setter injection, you're welcome to visit any of the projects i worked on when i was at Pivotal!

I am guilty of this too. It's why I'm a bit of a constructorist these days.

Aargh. I meant using constructor injection. It didn't save us.

Re: Spring vs. Java EE

#118

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…

> "Have the Spring team already solved this?" Almost every time the answer for me has been "it seems like they have, but they don't handle a critical edge case of some kind and cannot be extended to, and thus their solution is totally useless."

I've had this experience too, sometimes.

I have also found them responsive to feedback.

Re: Spring vs. Java EE

#119

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…

> Meanwhile, Oracle owns a lot of Java products That doesn't make Oracle bad or Pivotal good.

Not what I intended to convey. I am saying that Oracle, like Pivotal and Red Hat, is interested in the relative balance of Spring and Java EE preferences in the community.
Post reply on HN