News for hackers. Stuff that matters.
Re:A bad citizen in Javaland (2006) by _asummers on Thursday December 03, 2015 @08:41AM (#10669471)
In modern Java, one uses things like dependency injection (Guice, Spring, whatever) for building up the services, and I find most programmers now abhor setters for their POJOs. Want a new Person object with a different name? Make a new one, it'll be okay, except in the most extreme of circumstances. Ephemeral memory is cheap. When an object comes back from a constructor, it should (in my mind at least) be immediately usable. People also enjoy the builder pattern, I've found. When you call .build(), it will do the internal checks to say if you screwed up, so you're guaranteed to never have a Person with no Organs. This is, of course a run time check so less helpful than a compiler error. Depending on the use case, it makes perfect sense, though.

Also side note, how do I do the code blocks in HN comments like you did?

Re:A bad citizen in Javaland (2006) by bencoder on Thursday December 03, 2015 @09:01AM (#10669557)
There's still a lot of getters everywhere though, which seemed to me to be the bulk of the analogy.

    this.wallet = colleague.getWallet();
Code blocks are done with 4 space indentation at the start
Re:A bad citizen in Javaland (2006) by reitanqild on Thursday December 03, 2015 @10:40AM (#10670142)
Which is not a fault of the Java language: trainwrecks (this->getThat()->getThose()-foreach(){ do stuff } is a general antipattern.

The correct way is IMO: colleague.getMoney() which can easily be implemented in Java, PHP etc.

I'm getting a bit tired of this constant pecking at Java (nothing personal). There are a number of questionable designs yes, there is a lot of ugly code out there, yes, but almost every alternative might have been worse:

Teaching everyone C? Good luck.

Switch to C#? Until recently that would prevent you from using Linux on your servers unless you were ready to put in technical effort and bet on MS not suing you or the upstream effort.

Perl?

PHP?

Catch my drift folks? Java filled a niche. It was almost as easy as PHP once you got started (although onboarding still is messy I think) and provided superior tooling.

Re:A bad citizen in Javaland (2006) by bencoder on Thursday December 03, 2015 @11:24AM (#10670439)
Despite the name, I didn't see the article as taking a pop specifically at Java. It seemed more about bad OOP in general. As you say, you'll see the same patterns in every OO language.
Re:A bad citizen in Javaland (2006) by lmm on Thursday December 03, 2015 @11:43AM (#10670562)
The story is explicitly about a bad citizen in Javaland.
Re:A bad citizen in Javaland (2006) by woah on Thursday December 03, 2015 @10:55AM (#10670241)
I think people just hate all the hoops you have to jump through to satisfy arbitrary constraints the language places upon you to conform to some pedantic definition of object orientation that only works well in textbook examples.

Not saying Java isn't a good choice for some things. Also, if functional programming languages were more popular, they would probably be subjected to the same ridicule for the same reasons.

Re:A bad citizen in Javaland (2006) by sevensor on Thursday December 03, 2015 @11:14AM (#10670364)
By the same token, I think the superior tooling is part of the reason people who aren't primarily Java users find it incredibly painful. I've seen Eclipse experts in action -- most of the work seems to be picking the right thing from a drop-down. All kinds of things just appear where they're needed. Accustomed as I am to typing source code, I can't quite get my head around it.
Re:A bad citizen in Javaland (2006) by workitout on Thursday December 03, 2015 @01:49PM (#10671666)
>> Which is not a fault of the Java language: trainwrecks (this->getThat()->getThose()-foreach(){ do stuff } is a general antipattern.

While I agree with you, isn't that what the new streams in Java does? The map reduce complex?

Re:A bad citizen in Javaland (2006) by steveklabnik on Thursday December 03, 2015 @11:42AM (#10670553)

  you only need two spaces, actually
https://news.ycombinator.com/formatdoc
Re:A bad citizen in Javaland (2006) by lmm on Thursday December 03, 2015 @11:42AM (#10670555)
Relying on dependency injection is even worse than setters. Will DI behave the same in tests as in real code? Are you sure?

The right thing is to use an actual constructor that takes constructor parameters. Guice and Spring can both handle this correctly (you just put the @Autowired on the constructor itself). The trouble is that in Java this requires ~twice as many lines as putting a magic annotation on your fields.

Re:A bad citizen in Javaland (2006) by pbh101 on Thursday December 03, 2015 @02:31PM (#10671920)
Especially in the multi-core era, this becomes more and more important. Thanks to the Java Memory Model specification, if you are using constructors (and yes, pretty much every DI framework by now has this feature), with just a bit of care[1] you can ensure that your object is never visible to any threads without it having been completely constructed.

[1] Make sure to not leak references to your object in your constructor. Most of the time that you would want to do this is starting a service or registering a handler, etc. The solution is to use a static creation method which first calls the constructor, and then registers/subscribes it, etc.