• NULLPTR (unregistered)

    comment* comment = (comment*)NULL;

  • P (unregistered)

    This WTF is indeed a gem

  • RLB (unregistered)

    Well, that explains the pile of almost-as-bad-as-MS-Windows-2 that my father got with his @%^trad-Schneider PC1640.

  • R (unregistered)

    That's the real issue with most WTFs.. if you actually fix them, they think you're insane and fire you.

  • (nodebb)

    She was wrong. Boolean is an object. Original developers were using object oriented principles. Whereas she didn't. Very unprincipled.

  • P (unregistered) in reply to Mr. TA

    And that's where you're wrong: she is thinking outside the box. A skill that only talented coders have

  • Vilx- (unregistered)

    These puns are getting ever more ternible!

  • King (unregistered)

    "..the unit tests were exemplary." WTF!!

  • a person (unregistered) in reply to King

    The tests were probably written by the single sane developer on the team before they were deemed unproductive and let go, because none of their code did anything relevant once deployed to production.

    Because as we all know, "lines of code that are executed in production" is a great metric by which to measure productivity.

  • (nodebb) in reply to P

    Quite the opposite, she elected to use primitives, which need to be boxed into reference types, as needed. She's literally thinking inside the box.

  • (nodebb)

    Who needs thinking inside or outside of the box when you have auto(un)boxing? Of course, that would put all those Youtubers filming them unpacking stuff out of business...

  • (nodebb) in reply to JiP

    You're not saying that .NET is better than JVM, are you? I hope not!!!

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    Boxing booleans into Booleans shouldn't ever result in heap allocations. The JLS requires that if a==b for boolean values, then boxing a and b must return identical objects. Likewise for int values between -128 and 127 and for char values between 0 and 127. So I wouldn't expect that all of the boolean fixes that Naomi made to affect the number of heap allocations, but all of the int fixes that she made very likely would do so.

    https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7

  • Kleyguerth (github) in reply to Anonymous') OR 1=1; DROP TABLE wtf; --

    It has been a while since I last worked with java, but I'm pretty sure if you use new Boolean() instead of Boolean.valueOf(), you create a new object and those optimizations do not apply. The submitted code is clearly using new Boolean()

  • Jake (unregistered)

    Doing all that refactoring (15k lines) as one commit is the real WTF.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered) in reply to Kleyguerth

    Derp you're right.

  • (nodebb)

    Just in case anyone missed the implicit reference about XML and regex,

    https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags

  • (nodebb) in reply to Mr. TA

    I am primarily a Java programmer with very little experience in .net. So no claims like that here...

  • (nodebb) in reply to Kleyguerth

    Yes, this would be a no-brainer. In Java, any call with the /new/ operator will always create a new object instance (and for that matter, execute the constructor method right after /new/). Therefore, the expression /new Boolean(false) = new Boolean(False)/ will /always/ return false. This may come as a surprise to non-Java coders. The proper way of doing what you probably intended is /new Boolean(false).equals(new Boolean(false))/. That will /always/ return true.

    Autoboxing any primitive type /may/ in practice result in a new object, but this is by all means not mandatory for the JVM and not-to-be-relied-on behaviour.

    Addendum 2019-09-04 11:51: (not sure what happened to my equals operator, of course where it says '=' above, it should say '=='. As written, it would obviously not even compile)

  • sizer99 (google) in reply to RLB

    Since this is Java, I don't think it's any relationship to the crappy old GUI named Gem either.

    Unless for some godforsaken reason someone decided to re-implement the whole C codebase in Java which, well, it's enterprisey so we can't rule that out entirely. But let's hope not.

  • (nodebb) in reply to Kleyguerth

    Not forgetting that all boxed primitive types are (normally) immutable, so you should never need to clone one, unless you specifically want == to fail. In other words, you should have been able to just write:

    this.isSided = gemGeometryEntryPoint.isSided;
  • Klaus (unregistered) in reply to Jake

    @Jake a 15kloc commit may seem insane, but if that commit is the result of automated refactoring, it seems rather reasonable to not split it.

  • (nodebb) in reply to Jake

    Instead of 15,000 one-line commits.

  • Martin (unregistered)

    You are all missing the big wft. Java Boolean is immutable(Can't change value), so there is no need to create a copy at all. A simple this.isSided = gemGeometryEntryPoint.isSided would be the perfect solution.

    Still a wft to use Boolean everywhere. I only ever use a Boolean when mapping a nullable database field to java, but there may be other use cases for a tristate boolean.

  • Harris M (unregistered) in reply to sizer99

    About that...

    http://nestedvm.ibex.org

  • Ulysses (unregistered)

    TRWTF is obviously boxing itself. Honorable mention goes to 'wft'. ;)

  • sizer99 (google) in reply to Harris M

    @Harris: Aieeeeee. Sincerely yours.

  • termit (unregistered) in reply to JiP

    The correct way would be to use Boolean.valueOf(...) which will always return one of Boolean.TRUE or Boolean.FALSE, which can be compared with ==, but given the described quality of the code base, looks like knowing that would be too much to expecte from the developers there.

  • markm (unregistered)

    The problem with committing a 15KLOC code change: The unit tests may be exemplary, but are they complete? When the software has a long history after the unit tests were first written, there would be changes made to handle quirks in the data or company procedures, and I would not trust that every programmer making those changes had updated the unit tests correctly, or even documented what the change was for. (The test passing does not always mean the code is AOK; sometimes the test doesn't work.)

    In fact, I would expect that many issues would be discovered after the big code change went into use. Breaking the changes up into several chunks would simplify tracking down those quirks.

  • Naomi (unregistered)

    Since I've seen a couple comments about the "15,000 line commit"... there may be some exaggeration for comedic effect going on in this article. It's been a few years, but I feel like it was slightly less than 3k in actuality, and it wasn't a single commit. I was a lot more careful than the article makes it sound like, and worked closely with our tester (who, IIRC, appreciated having some meaningful work for a change - yeah, that should tell you something).

    On the other hand, now that I'm not a green-behind-the-ears intern who feels she has to prove herself? I don't think I'd have done anything like that. I guess that's what they call hindsight. Still, they kept inviting me back, and the only thing I heard about "Gem" was that it was more stable than it had been (I got myself subscribed to the bug tracker), so I guess I did something right.

  • OlegYch (unregistered)

    the real wtf is "greatly improved performance", not to mention "unit tests were exemplary"

Leave a comment on “Boxing with the InTern”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article