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

41–50 of 119 posts

Re: Spring vs. Java EE

#41

Post by spiralpolitik »

specialist wrote: post #21
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.

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.

Re: Spring vs. Java EE

#42

Post by narak »

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…

http://sparkjava.com/

Definitely not all batteries included, but a great minimalist web library to get started with.

Re: Spring vs. Java EE

#43

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

Re: Spring vs. Java EE

#44

Post by manyxcxi »

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…

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.

Re: Spring vs. Java EE

#45

Post by manyxcxi »

edem wrote: post #33
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.

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're green to it and there isn't a grizzled vet around, but if you're trying to build for more than contrived simple solutions that you need to monitor, scale, and secure I don't know anything else out there that gets you so far down the road almost at the beginning.

Re: Spring vs. Java EE

#46

Post by iampims »

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…

Dropwizard is one of the simplest way to get started and remains well suited for larger applications:

http://www.dropwizard.io/1.1.0/docs/getting-started.html

Re: Spring vs. Java EE

#47

Post by abalone »

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…

These are good answers but nowadays we would be remiss not to mention so-called "serverless" frameworks. Dropwizard et al are good suggestions for running your own instance, but more and more the serverless approach is an attractive alternative to implementing a web app.

AWS Lambda now supports Java, so perhaps we could consider API Gateway, Cognito and DynamoDB/Aurora as one of the new "frameworks". Google has their own competing offering as well, e.g. Cloud Functions. Firebase deserves a special mention as a rapid development framework, although at the moment it only supports Node.js. Like many frameworks it has pros and cons, but in my opinion full-on websockets support OOTB is a pretty cool pro.. especially since Lambda/Cloud Functions/FaaS can't do websockets on their own.

Re: Spring vs. Java EE

#48

Post by manyxcxi »

specialist wrote: post #21
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.

I laughed harder than I should've because I just moments ago was reviewing a stack trace with a teammate and questioned "have you ever gotten anything useful after line 50 of a Spring stack trace?"

And then we all laughed until we realized half the trace was because it got logged and thrown and then logged again...

Re: Spring vs. Java EE

#49

Post by twic »

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

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!

Re: Spring vs. Java EE

#50

Post by twic »

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

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 coarser-grained objects. Why? Because you need to have enough functionality to test; with fine-grained objects, you have to construct and assemble an object graph in the test, whereas with coarse-grained objects, you just new up one thing.

Post reply on HN