• dpm (unregistered)

    Sorry, I'm a long-time reader and have enjoyed this site for years, but there is zero chance I'm going to read that much code. It can't be amusing enough to be worth it.

  • Prime Mover (unregistered)

    I've always wondered why Java has the Iterator class and various List and Map objects if all everybody seems to do is implement everything as an array with indices.

    Similarly, what on earth is the point of the List interface? Nobody ever uses it. They just trundle on brainlessly casting direct to ArrayList.

  • (nodebb) in reply to Prime Mover

    It smells like they thought they knew what the structure of the classes should be, but were mistaken. There are more things in the Java type system than in .NET where you look at it and go "WTF?"

  • Andrew (unregistered) in reply to Prime Mover

    When you cast List to ArrayList, you should ask yourself what's so special and specific about ArrayList that you can't use it as a generic list.

    In my experience, there isn't anything special about it 100% of the time, so I don't cast.

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

    Based on the diff, both classes share the same serialVersionUID which is not supposed to be the case. If those classes actually use Java's built-in serialization, that'd break badly at runtime, which tells me that they're not using Java serialization (pretty common) and they just added those serialVersionUIDs to silence the lint warnings about their lack.

  • Sole Purpose Of Visit (unregistered) in reply to Andrew

    Well, since ArrayList extends the AbstractList class, which implements the List interface ... the main thing you have to ask yourself in Java is whether or not you are dealing with an ArrayList. Otherwise you are downcasting to a null, as far as I can see.

    And given this Java inheritance hierarchy (assuming I have it right), your ArrayList already does everything that a List does, you'd be mad to write code that accepts a List but requires the extra functionality of an ArrayList. Because unless the collection is indeed an ArrayList, that functionality is not there.

    The problem, I assume, comes when you as the call site want to invoke a method that depends upon an ArrayList, but what you actually have is a List (or possibly an AbstractList). I'm wide open to correction here, because I have studiously avoided Java for twenty five years and six or seven major versions of the language, but as far as I can see you'd need to try a Java.lang.Class.cast() from a List to an ArrayList. Which, unfortunately, might result in a ClassCastException.

    From a C# perspective, it all looks a bit messy. (Though I could very well be wrong.) Of course, in the general case, you'd just refactor methods to accept a List rather than an ArrayList, but that might not go down too well when you're dealing with a million line code base.

  • ooOOooGa (unregistered) in reply to dpm

    If you have been here for years, then you should already know that this certainly isn't the longest block of code posted in its entirety.

  • Rob (unregistered)

    The listColumnNames method should have been static. It doesn't depend on any single instance. However, instead of using TableColumns.listColumnNames(), anyone using it is now forced to use an instance: TableColumns.Label.listColumnNames() or TableColumns.Color.listColumnNames().

  • "Just in case" is right (unregistered)

    Seems like a big case of the "just-in-case's". Just in case YLineGraphTableModel needs to diverge from XLineGraphTableModel, it's been made into its own class. What a waste! Kind of goes to show how little planning was done at the very beginning.

  • Jeremy (unregistered)

    Well this is a pretty literal example of an XY-problem

  • MaxiTB (unregistered)

    To a C# developer like me, this code looks like spaghetti code to me. Casing is all over the place, and everything looks so alien. Like there's no property and enums are just syntactical sugar instead of real, well, enums. So strange. I couldn't really tell if it's good Java code, cause to me it just looks like bad C++ code.

  • Nick (unregistered)

    It appears that there’s a field named “lgm” in the abstract class, which is accessed by both the X and Y implementations.

    Significantly, the X implementation gets the “X” data from this field, whereas I assume the Y implementation uses the “Y” data from that class - the line showing “lgm.getXDataSeriesSettings” in the diff isn’t just a renamed variable, it’s a significant difference.

    Ideally, the developer would have created an abstract “getSeriesSettings” method in the parent class, rather than re-implementing getValueAt and setValueAt in their entirety. Overall though, this isn’t nearly the WTF the article seems to suggest.

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

    Based on the diff, both classes share the same serialVersionUID which is not supposed to be the case. If those classes actually use Java's built-in serialization, that'd break badly at runtime,

    This is not correct. The serialVersionUID is a version number for the class. If you serialise an instance of the class and then make incompatible changes to it, you bump the serialVersionUID so that the deserialiser knows that it can't deserialise the old data. It's absolutely fine for two different classes to have the same serialVersionUID. Essentially, it's just a version number for that class.

    which tells me that they're not using Java serialization (pretty common) and they just added those serialVersionUIDs to silence the lint warnings about their lack

    This is almost certainly true. It's true of pretty much all the Java code I ever wrote using Eclipse, until I understood what it was really for.

Leave a comment on “A Repetition of Repetition to Repeat”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article