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

71–80 of 119 posts

Re: Spring vs. Java EE

#71

Post by jacques_chester »

twic wrote: post #49
jacques_chester wrote: post #11

Earlier quoted context omitted.

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!

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

Re: Spring vs. Java EE

#72

Post by jacques_chester »

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

> The idea that you would add a dependency to avoid writing a try-catch in a loop is absolutely bewildering to me.

Reliable retry is very important in some cases, and it's easier to test a retry-agnostic unit of code.

Edit: and I also rather like that it's declarative, rather than needing to infer intention or write my own boilerplate to explicate intention.

Re: Spring vs. Java EE

#73

Post by jacques_chester »

EdwardDiego wrote: post #66
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 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.

> I have an aversion to setter/field based injection because it allows you to instantiate an object in an incorrect state.

Oh yes. I recognise that JavaBeans had its reasons for being, but then you get to JPA and it's time for all the boggling.

Re: Spring vs. Java EE

#74

Post by jacques_chester »

EdwardDiego wrote: post #65
twic wrote: 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…

If you're firm on constructor injection, you can typically test the object in complete isolation without necessarily using mocks, without Spring having to be involved.

Or you can use mocks and Spring Boot's test annotations.

But with field/setter injection, that choice isn't as easy.

Re: Spring vs. Java EE

#75

Post by jacques_chester »

stickfigure wrote: post #70
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 d…

Is this an argument for using something like protobufs?

Re: Spring vs. Java EE

#76

Post by rodgerd »

stickfigure wrote: post #70
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 d…

I've witnessed a similar journey, having worked on an application 15 years ago that (for various reasons that made sense at the time) used RMI calls between a bunch of presentation logic and a service layer.

It was refactored into a J2EE application after 7 years, and is now being refactored into a group of microservices, which causes a number of the longer-lived devs in the team to suggest everything old is new again.

Re: Spring vs. Java EE

#77

Post by manyxcxi »

abalone wrote: post #55
manyxcxi wrote: post #51

Earlier quoted context omitted.

RE: AWS Lambda, there are a lot of shortcomings, the biggest is latency when it's cold. Another is duration, if your process takes too long and you can't break it into smaller steps (probably not a good sign, but still...) Lambda is no-go. Configuration generally kind of sucks to manage, you don't get some of the role inheritance you can get from standard EC2/IAM, and forget running inside a VPC. The idea behind usin…

There's a lot to criticize about running your own Dropwizard, Play, Spring and Java EE instances as well, including the same issue of management headaches. In fact one of the key advantages of the "serverless" approach is less devops management overhead. To consider running your own instance "management suckage free" but calling something like serverless.com a headache is definitely not an apples-to-apples comparison…

I definitely didn't downvote and I agree that there are tradeoffs with any choice- but serverless doesn't mean Ops-less. I use Lambdas for lots of things, actually a lot of my Ops use Lambdas for various tasks (like SES catch all mail forwarding for example).

Don't think I'm dissing Lambdas (or anything like them in a non AWS context). There's a lot to love about them, not the least of which is that for small (in time to completion, request volume, and memory usage) units of work they are significantly cheaper.

There's a config management nightmare for everything but there are known ways to answer it for a traditional server/fleet approach. Run time configuration of Lambdas is still evolving and there aren't many options to choose from that are much better than just deploying the code and config as one as part of a delivery pipeline. It's workable now, but there are gaps. There aren't any gaps with running your own applications, it's literally what's always been done. There are certainly pain points, but the problem is already well understood.

Re: Spring vs. Java EE

#78

Post by Consultant32452 »

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…

This question usually comes from a person trying to build their resume. My suggestion would be to do a search for Java jobs in your area and see what other libraries they are using. That will be way more useful to you in the long run than learning what the HN crowd thinks is fashionable. In my experience around here that means Spring, but it could be different in your area..

Re: Spring vs. Java EE

#79

Post by 16bytes »

stickfigure wrote: post #70
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 d…

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.

Re: Spring vs. Java EE

#80

Post by reitanqild »

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…

I'd (of course for those who know me) suggest taking a little time to learn JavaEE (not J2EE).

I have had great success with the examples from TomEE (free) + the (paid) videos from Adam Bien (I normally shun videos but lke his).

The examples from TomEE often come in the form of something you can run with a single maven command.

Post reply on HN