> The JavaBean idea arose because early versions of Java had no way of performing introspection

Not quite. Java has had introspection since 1996. What JavaBeans brought is a consistent way of naming your methods so that classes can be introspected and made sense of in a way that allows composition and interaction.

I stand corrected. :)

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?

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

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.

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.

The story is explicitly about a bad citizen in Javaland.

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.

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.

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

  you only need two spaces, actually

https://news.ycombinator.com/formatdoc

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.

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.

> (For those that don't remember: The JavaBean idea arose because early versions of Java had no way of performing introspection, something that software tools really, really need. JavaBeans broke object encapsulation by design. Many programmers had to write beans to take advantage of their tools, and learned a very bad habit.)

I have wondered what that was about. Thanks for clearing it up.

It is strange how the lack of a feature people really need (or want) can cause them to do weird things to work around that lack.

Yeah same, to me it seemed like poking fun at bad OOP practices more than anything, and the last paragraph is just casting garbage collection in a funny way.