5 ms·

I was about to dismiss this story as silly, but then it occurred to me that the reason this is so funny is not because Java is a bad language per se, but that i

by jt2190 11y ago

I was about to dismiss this story as silly, but then it occurred to me that the reason this is so funny is not because Java is a bad language per se, but that it really didn't work well for programmers who don't understand Object Orientation. I've read more than my fair share of code that reads exactly like this story because of this lack of programmer understanding. Consider: You are born with no body parts. Person me = new Person(); Should anyone attempt to interact with you before your organs have finished arriving you will die. me.interact(); Throws a NullPointerException because the class designer improperly initialized the instance. The designer should have provided a constructor. public static Person() { this.organs = new Organs(); } One by one, your organs are pushed into you. Instead, the class designer probably followed the JavaBean pattern and provided a setter method for Organs: public void setOrgans(Organs organs) { this.organs = organs; } 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.)

_asummers 11y ago
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?
- bencoder 11y ago
  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
  - reitanqild 11y ago
    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.
    - woah 11y ago
      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.
    - sevensor 11y ago
      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.
    - bencoder 11y ago
- lmm 11y ago
  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.
  - pbh101 11y ago
    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.
joonoro 11y ago
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.
incepted 11y ago
> 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.
- jt2190 11y ago
  I stand corrected. :)
krylon 11y ago
> (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.

by jt2190 11y ago

_asummers 11y ago

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?

bencoder 11y ago
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
- reitanqild 11y ago
  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.
  - woah 11y ago
    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.
  - sevensor 11y ago
    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.
  - bencoder 11y ago
lmm 11y ago
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.
- pbh101 11y ago
  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.

joonoro 11y ago

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.

incepted 11y ago

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

jt2190 11y ago
I stand corrected. :)

krylon 11y ago

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