• (cs) in reply to brazzy
    brazzy:
    Matt:
    Geekwad:
    What if you don't want data, you want a model?

    And I do. I'm just not sure that Java is the best way of getting one...

    If you want a model, anything to do with computer programming is a rather bad way; try doing rock music or acting instead.

    I tried the rock music thing for a few years back in the 80's. We did ok but you would never know about us now. The point here though, is that the models we attained were more of the penthouse variety, moderately good looking, easy, and came with free pizza and beer. The order of importance of those three factors varied greatly from one day to the next.

  • Some Guy Plugging Spring (unregistered) in reply to Geekwad
    Geekwad:
    gabba:
    Geekwad:
    "I can't imagine a single scenario ..."

    What if ...

    How about that? I think we found the guy who wrote today's wtf.

    Look, my point is, the WTF being presented is that someone applied a bunch of design patterns to something trivial. But, the "something trivial" is never described. We are encouraged to infer it is trivial because it probably involves a boolean value, but there's no real information. We are given evidence that several well-known patterns are being used, but we are given no evidence that they are being mis-used. We're holding some developer up for ridicule based on nothing more than some path names. That sounds pretty WTF to me.

    From the article: "For a class that has a value of either yes or no." That sounds awfully like a boolean value to me.

    Also, get it straight, the developer (who is anonymous) is not up for ridicule. His or her heavily over-engineered code is up for ridicule, because it is, well, ridiculous.

    Even if you've got ample reason to do this sort of thing, (you need a custom ORM solution for your database, you need to process documents in multiple languages, etc.) there are much better ways than rolling your own. For example, Spring:

    http://www.springframework.org/

    Every Java programmer should get familiar with Spring. If you don't see any use for it, congratulations, your code will probably be featured on this site in the future. If you do see a use for it, you'll remember the day you read about this library on WTF, and how cool it was to find something so damn useful it hurts.

    CAPTCHA: scooter (should have served jail time!)

  • Anthony (unregistered) in reply to charon

    Classes don't store values?! Did you forget what web site you're on? Around here, it's generally expected behavior for classes to store values. Its best to create a new class every time you want a new value.

    For example (untested):

    package ValueFactory;
use Symbol qw(qualify_to_ref);

my %instances;
my $next_instance = 0;

sub GetInstance {
  my ($self, $value) = @_;

  unless (exists $instances{$value}) {
    my $class = "ValueFactory::Instance$next_instance";
    my $new = qualify_to_ref('getValue', $class);
    *$new = sub { $value }
    $instances{$value} = $class;
    ++$next_instance
  }

  return $instances{$value};
}
  • (cs) in reply to Some Guy Plugging Spring
    Some Guy Plugging Spring:
    http://www.springframework.org/

    Every Java programmer should get familiar with Spring. If you don't see any use for it, congratulations, your code will probably be featured on this site in the future.

    Or, you're supremely lucky enough to never have to develop in Java.

    /and nobody gives a flying failure what your failing CAPTCHA is

  • Paul (unregistered)

    Where's the unit tests?

  • (cs)

    Since the result of YesNoFactory.getFactoryInstance().YES.getDescription().equals(array[0].toUpperCase()); is a String of length one that respresents Yes or No, this is completely conformed and ready for XML. That makes it fully Enterprise-ready!!!!

  • Nat` (unregistered)

    "YesNoFactory.getFactoryInstance().YES..."

    Anyone else notice that this expression does not even call a method of the factory at all? It appears to be using an instance reference to refer to a constant (public static final) value defined in the YesNoFactory interface or class. So the factory is entirely pointless.

  • s. (unregistered) in reply to Anon
    Anon:
    Java enums are allowed to be null, which destroys their usefulness as an enum. It's just like Java's "generics", it's just syntactic sugar, and ultimately worthless.

    Actually, I love such 'three-state booleans', be it 'null', 'undef', '!isset' or whatever the language provides as the third state. The three states are "TRUE", "FALSE" and "DON'T TOUCH THE FUCKING DEFAULT". Makes passing boolean parameters down the inheritance tree much more convenient.

  • LucyLuSatisfied (unregistered) in reply to WWWWolf

    You are definitely one of my top nominees for humanities greatest WTF ever prepared!

    Congrats!

  • (cs) in reply to charon
    charon:
    For a class that has a value of either yes or no.

    Classes don't store values, their instances do (in properties).

    Ever heard of static methods and variables?

    No clue if that's the case here, but saying "classes don't store values, their instances do" is wrong.

  • mh (unregistered) in reply to ParkinT
    ParkinT:
    Since the result of YesNoFactory.getFactoryInstance().YES.getDescription().equals(array[0].toUpperCase()); is a String of length one that respresents Yes or No, this is completely conformed and ready for XML. That makes it fully Enterprise-ready!!!!
    With the exception of the hard-coded zero, which should have been read from an XML-based configuration file (in a culture-neutral format, natch) accessed via a web service on a 3 tier architecture.

    God help us all.

  • zombies! (unregistered) in reply to Richard
    Richard:
    Maarten:
    CAPTCHA: onomatopoeia

    Do I care?

    You sure do. Mine's sanitarium, BTW.

  • Jax (unregistered)

    I'd laugh if it wasn't for the fact I just spent the last couple of months purging this same kind of drivel from the code base I have inherited in my current contract.

  • Matt (unregistered) in reply to brazzy
    brazzy:
    Matt:
    Geekwad:
    What if you don't want data, you want a model?

    And I do. I'm just not sure that Java is the best way of getting one...

    If you want a model, anything to do with computer programming is a rather bad way; try doing rock music or acting instead.

    Your faith in my guitar playing is touching. Misplaced, but touching.

    I like to tell people that I play a unique style of music where I take well-known songs and play them REALLY slowly and make lots of mistakes...

    I also point out that if I could get someone to pay me what I make as a programmer to practice the guitar for 8 hours a day (plus emergency off-hours/weekend work), I'd be Steve Freakin' Vai by now. :)

  • Java Fan (unregistered) in reply to Zylon
    Zylon:
    Some Guy Plugging Spring:
    http://www.springframework.org/

    Every Java programmer should get familiar with Spring. If you don't see any use for it, congratulations, your code will probably be featured on this site in the future.

    Or, you're supremely lucky enough to never have to develop in Java.

    /and nobody gives a flying failure what your failing CAPTCHA is

    If you don't develop in Java, you don't know what you're missing.

  • Laie Techie (unregistered)

    I use Booleans to represent 3 values - true, false, and I don't care.

    captcha: what a tastey morsel.

  • (cs) in reply to Java Fan
    Java Fan:
    Zylon:
    Some Guy Plugging Spring:
    http://www.springframework.org/

    Every Java programmer should get familiar with Spring. If you don't see any use for it, congratulations, your code will probably be featured on this site in the future.

    Or, you're supremely lucky enough to never have to develop in Java.

    /and nobody gives a flying failure what your failing CAPTCHA is

    If you don't develop in Java, you don't know what you're missing.

    That's sort of like saying "If you haven't been to Hell, you don't know what you're missing".

    We could probably take a pretty good guess.

  • dkf (unregistered) in reply to Nat`
    Nat`:
    "YesNoFactory.getFactoryInstance().YES..."

    Anyone else notice that this expression does not even call a method of the factory at all? It appears to be using an instance reference to refer to a constant (public static final) value defined in the YesNoFactory interface or class. So the factory is entirely pointless.

    On the evidence given there's no way to be sure that that variable is either static or final. Of course, using that naming scheme for something non-static and/or non-final would be good reason for shooting the author of the code. It'd be for his own good.

  • SkittlesAreYum (unregistered) in reply to Anon
    Anon:
    Since Java enums are objects (another WTF for another time), you're allowed to invoke methods on them. You can't invoke methods on a null object. A simple example would be the name() method which returns the name of the constant.

    By allowing null to be a legal value, you break the entire concept of a Java enum. Which, since Java allows null enums, is already broken.

    Um, what? First of all, you think enums being objects are a WTF? I imagine you'd hate SimpleTalk, in which everything (even numbers) were objects.

    Second of all, I fail to see how allowing an enum to be null breaks the entire concept, or at least for the example you gave. Of course you can't invoke methods on a null object - so what? You can't invoke methods on a null pointer in C++ either; does that make them broken?

    I haven't done much work with Enums in Java, so I don't know a whole lot, but you sure haven't convinced me they are broken.

  • (cs)

    Whipped up some quick prototype code and spent all day banging my head against the wall debugging it. See, our program uses different kinds of connectors, and consequently different kinds of pools of said connectors. I was adding a new connector (so copy/pasted QueueConnector and modified it slightly) and a new Pool (so copy/pasted FilePool and modified it slightly).... The reason it was broken all day?

    FileConnector.java:
    private volatile AtomicBoolean fileConn = new AtomicBoolean(false); public volatile static AtomicBoolean FTrue = new AtomicBoolean(true); public volatile static AtomicBoolean FFalse = new AtomicBoolean(false); 
    public AtomicBoolean getActiveState() { return this.fileConn; }
    QueueConnector.java and MyConnector.java:
    private volatile AtomicBoolean conn = new AtomicBoolean(false); public volatile static AtomicBoolean QTrue = new AtomicBoolean(true); public volatile static AtomicBoolean QFalse = new AtomicBoolean(false); 
    public AtomicBoolean getActiveState() { return this.conn; }
    MyPool.java:
    if(connector.getActiveState() == File.FTrue) //Do important stuff

    Now the guy who originally coded it is trying to convince me that there's a reason to have two different kinds of bools.

    "truth is in the abstract base class of the beholder thread" i guess.

  • (cs) in reply to vt_mruhlin
    vt_mruhlin:
    Whipped up some quick prototype code and spent all day banging my head against the wall debugging it. See, our program uses different kinds of connectors, and consequently different kinds of pools of said connectors. I was adding a new connector (so copy/pasted QueueConnector and modified it slightly) and a new Pool (so copy/pasted FilePool and modified it slightly).... The reason it was broken all day?
    FileConnector.java:
    private volatile AtomicBoolean fileConn = new AtomicBoolean(false); public volatile static AtomicBoolean FTrue = new AtomicBoolean(true); public volatile static AtomicBoolean FFalse = new AtomicBoolean(false); 
    public AtomicBoolean getActiveState() { return this.fileConn; }
    QueueConnector.java and MyConnector.java:
    private volatile AtomicBoolean conn = new AtomicBoolean(false); public volatile static AtomicBoolean QTrue = new AtomicBoolean(true); public volatile static AtomicBoolean QFalse = new AtomicBoolean(false); 
    public AtomicBoolean getActiveState() { return this.conn; }
    MyPool.java:
    if(connector.getActiveState() == File.FTrue) //Do important stuff

    Now the guy who originally coded it is trying to convince me that there's a reason to have two different kinds of bools.

    "truth is in the abstract base class of the beholder thread" i guess.

    It appears the author didn't understand what AtomicBoolean is for. Returning an AtomicBoolean from a public method is a sign that someone doesn't grasp what AtomicBooleans are. (Hint: they're mutable. Returning mutable private fields is usually bad, and using mutable objects as public static "constants" is usually bad.)

    There's other issues in what you've quoted, but I'll leave them for others to notice.

  • Coximus (unregistered) in reply to Kuli

    That was my first thought too - code generation. Nothing like a good ole' code generator to churn out thousands of lines of code. Doesn't really matter until you have to modify by hand.

  • d (unregistered)

    captcha test

  • (cs)

    For those who have had to deal with inappropriate factories and haven't read this already: Why I Hate Frameworks. A very funny article on 'Joel on Software' about frameworks and their factories.

  • ac (unregistered) in reply to brazzy
    brazzy:
    Non sequitur. Just because something is similar to but doesn't work exactly like the corresponding construct in your favorite language does not make it worthless. Snytactic sugar most certainly isn't, or would you prefer your C without the [] operator (syntactic sugar for pointer arithmetics), without structs (syntactic sugar for multiple variables) and without methods (syntactic sugar for goto)?

    Except neither functions nor structs are just syntactic sugar. You can't store labels into variables nor cast random pointers to whatever types without alignment issues.

  • Knitpik (unregistered)

    The real WTF is using Java to do anything at all. It's a sh|t language.

  • Jerome (unregistered) in reply to Kuli
    Kuli:
    I wouldn't care about such thing. They get generated, and then? Who cares? They don't eat bread.

    Exactly right my friend. That's what the so-called experts here don't seem to realise. You can't have a true WTF unless it eats bread.

    BTW, whatever you're smoking, save some for me.

  • Marvin (unregistered)

    And it doesnt even handle FileNotFound...

  • Foo (unregistered) in reply to Richard
    Richard:
    Maarten:
    CAPTCHA: onomatopoeia

    Do I care?

    CAPTCHA: digdug

  • Rob B (unregistered)

    The author should be taken outside and poked with sharp wooden sticks until they repent of their sin.

    It's so bad it's not even funny; if some who worked for me came up with a 'solution' like that I'd seriously consider firing them.

    I saw something similar once-upon-a-while; for a gas metering system, a Premises class had a Meter class, which had a Dial class that had an ordered collection class of Digit classes each of which had a Value property...

  • csrster (unregistered) in reply to SkittlesAreYum
    SkittlesAreYum:
    Anon:
    Since Java enums are objects (another WTF for another time), you're allowed to invoke methods on them. You can't invoke methods on a null object. A simple example would be the name() method which returns the name of the constant.

    By allowing null to be a legal value, you break the entire concept of a Java enum. Which, since Java allows null enums, is already broken.

    Um, what? First of all, you think enums being objects are a WTF? I imagine you'd hate SimpleTalk, in which everything (even numbers) were objects.

    Second of all, I fail to see how allowing an enum to be null breaks the entire concept, or at least for the example you gave. Of course you can't invoke methods on a null object - so what? You can't invoke methods on a null pointer in C++ either; does that make them broken?

    I haven't done much work with Enums in Java, so I don't know a whole lot, but you sure haven't convinced me they are broken.

    I'm not sure I even know what mr. anon is saying - is he suggesting that MyEnumClass.AN_ENUM_VALUE can be null? How? Or does he just mean that a reference variable of enum type can be null at runtime? The latter is obviously true. How would you prevent it? The compiler can't detect possible NullPointerException-s before they happen.

    (And, btw, let's have no more talk about "null objects" unless we mean the Null Object Pattern. "null" in Java isn't an Object.)

  • (cs) in reply to Rob B
    Rob B:
    The author should be taken outside and poked with sharp wooden sticks until they repent of their sin.

    It's so bad it's not even funny; if some who worked for me came up with a 'solution' like that I'd seriously consider firing them.

    I saw something similar once-upon-a-while; for a gas metering system, a Premises class had a Meter class, which had a Dial class that had an ordered collection class of Digit classes each of which had a Value property...

    The 'author' was almost certainly a code generation tool. Those things are hard to poke with sticks.

  • (cs) in reply to KattMan
    KattMan:

    Actually you are partly wrong. Enums are fine having null values and remaining as such and this makes them NOT a boolean.

    Booleans (in most languages) are two valued variables that can have a third state of uninitialized. This state effectively means null. Now if you can not safely assume a null value is actually one of two predefined values you do not have a boolean.

    For example, you can have a boolean for a finished state, true means finished, false mean unfinished. If the value is uninitialized you can assume false because if the item was finished the boolean would have been specifically set to true.

    Alternatively, the safe value could be True for booleans that mean something else such as an incomplete flag. In this case null = true because of the usage and name of the boolean variable.

    So yes internally there are three theoretical states for a boolean variable but the null state should be safely assumed to be one of the other two states and when encountered the boolean can be safely initialized to that state effectively getting rid of all null issues.

    So while the null = false statement isn't really correct, the idea behind the state is spot on. And even though java makes all enums an object and null objects don't allow the methods to be called, one used as a boolean can be safely initialized to it's safe state and then used.

    If the value hasn't been initialized, you can't assume it means anything. Just throw a runtime exception because you are in an invalid state and move on with your life.

    Now of course if you just use lower case booleans, Java enforces this for you by requiring them to be initialized before it ever gets used. Upper case Booleans are just intended to be wrappers for those primitives so that they can be used in things that only take Objects such as collection classes.

  • (cs) in reply to nwbrown
    nwbrown:
    KattMan:

    Actually you are partly wrong. Enums are fine having null values and remaining as such and this makes them NOT a boolean.

    Booleans (in most languages) are two valued variables that can have a third state of uninitialized. This state effectively means null. Now if you can not safely assume a null value is actually one of two predefined values you do not have a boolean.

    For example, you can have a boolean for a finished state, true means finished, false mean unfinished. If the value is uninitialized you can assume false because if the item was finished the boolean would have been specifically set to true.

    Alternatively, the safe value could be True for booleans that mean something else such as an incomplete flag. In this case null = true because of the usage and name of the boolean variable.

    So yes internally there are three theoretical states for a boolean variable but the null state should be safely assumed to be one of the other two states and when encountered the boolean can be safely initialized to that state effectively getting rid of all null issues.

    So while the null = false statement isn't really correct, the idea behind the state is spot on. And even though java makes all enums an object and null objects don't allow the methods to be called, one used as a boolean can be safely initialized to it's safe state and then used.

    If the value hasn't been initialized, you can't assume it means anything. Just throw a runtime exception because you are in an invalid state and move on with your life.

    Now of course if you just use lower case booleans, Java enforces this for you by requiring them to be initialized before it ever gets used. Upper case Booleans are just intended to be wrappers for those primitives so that they can be used in things that only take Objects such as collection classes.

    Actually you are wrong. If you are working with a true boolean state and you see one that is not initialized then you can and should the default safe state and continue. If you can not assume a safe state you are not working with a boolean.

    I gave two examples of valid booleans that you can assume a state with, now let's think of one that many people incorrectly assume they can use a boolean for, gender. If you assume 1 is male and 0 is female and you see an uninitialized gender variable, what is the safe decision? There is none. This is a third state and therefore not a boolean which is defined as two state. So you now have Male Female and unspecified.

    How you handle the unspecified is up to the application, some may raise an error if this info is required, some may accept the unspecified state as a valid value and assume this state. It still is not a boolean. Simply throwing an exception is not always the right decision, sometimes it is, but not always. You can sometimes make assumptions about missing data that will always be correct.

  • (cs)

    For the life of me, I cannot think of something like that. I mean it takes balls and brains to even imagine such a convoluted strange and overly complex system.

  • Bill White (unregistered)

    In the C++ program I work with we have scads of code to deal with booleans. We make a debugger. We need to read the binary files and interact with dozens of different versions of compilers. It turns out that for C and C++ the underlying data type for boolean may be signed or unsigned, but there is not a lot of other choices. For Fortran, the representation of True and False are not standardized. Sometimes 0 is false, 1 is true and everything else is undefined. Sometimes -1 is true, sometimes -1 is false. This can all happen on the same system, but with different compilers.

    So, if this is a code from a Java implementation of a Fortran debugger, it might very well need more than 150 lines of code do do the right thing. Unless you can see the code, and you know what it's there for, you can't tell if it's right or wrong.

  • (cs)
    jewnumeration:
    dude, null means false.

    No it doesn't.

    When dealing with Boolean objects, null means null. OTOH, the boolean primitive is false if not explicitly set.

    HTH.

  • (cs) in reply to abickerton
    abickerton:
    jewnumeration:
    dude, null means false.

    No it doesn't.

    When dealing with Boolean objects, null means null. OTOH, the boolean primitive is false if not explicitly set.

    HTH.

    Please read my statements above. With boolean objects null = the safe assumption. If there is no safe assumption and you retain the null you now have a third value to consider, it is no longer a boolean but now a three state enum.

  • (cs) in reply to Bill White
    Bill White:
    In the C++ program I work with we have scads of code to deal with booleans. We make a debugger. We need to read the binary files and interact with dozens of different versions of compilers. It turns out that for C and C++ the underlying data type for boolean may be signed or unsigned, but there is not a lot of other choices. For Fortran, the representation of True and False are not standardized. Sometimes 0 is false, 1 is true and everything else is undefined. Sometimes -1 is true, sometimes -1 is false. This can all happen on the same system, but with different compilers.

    So, if this is a code from a Java implementation of a Fortran debugger, it might very well need more than 150 lines of code do do the right thing. Unless you can see the code, and you know what it's there for, you can't tell if it's right or wrong.

    I thought about this initially thinking it wouldn't matter because if you compiled the application it knows what is true or false and checking the value with a if(booleanVar) would always return correctly. Then I thought about multiple systems interacting and therein lies the problem. The lack of standards can make this a problem.

  • FileNotFound (unregistered) in reply to jewnumeration
    jewnumeration:
    Anon:
    Coffee Maker:
    Except that until recently, Java didn't have ENUMs...
    Still doesn't. If you were to try and create a Boolean as a Java enum, you'd wind up with three values.

    Java enums are allowed to be null, which destroys their usefulness as an enum. It's just like Java's "generics", it's just syntactic sugar, and ultimately worthless.

    Dude -- null means false.

    No way. null means FileNotFound. DUH.

  • fluffy (unregistered)

    The real WTF is that the bool return of .equals() isn't being converted back to a YesNo instance.

  • anon (unregistered)

    I dunno. Looks pretty standard... for Java.

  • Phil (unregistered)

    It looks like it was probably spit out by some code generator. I would rather have this than to have to treat this entity different than all the other generated entities.

  • Chris (unregistered)

    The real WTF are all the people that think this isn't a work of fiction.

  • PhysicsPhil (unregistered)

    Boolean is the wrapper class for boolean primitives.

    CAPTCHA: onomatopoeia. No stupid joke, just a whinge about insanely long CAPTCHAs

  • PhysicsPhil (unregistered) in reply to KattMan

    javac (the Sun Java compiler) seems to give a compiler error if it thinks it is possible that a variable may be initialised before use. With a Boolean object, if it is uninitialised, you get a NullPointerException, with a boolean primitive, you get a compiler error. 0 does not evaluate to false in Java, and you cannot use: [code}int foo= 42; if(foo)[/code] although a null object does evaluate to false.

    In some cases it will warn even if it is impossible for the variable to be uninitialised: for example:

    if(LongAndCompexBooleanExpression){
   doStuff;
   foo = true;
}
else{
    doOtherStuff;
    foo = false;
}
...
if(foo)

    was rejected by the compiler, presumably because it did not realise that there was no way that you could I was not allowed to write if(foo=...) by the coding standards for the course I was studying, and there was a good reason at the time for not setting foo outside the if-statement beforehand

  • cdeszaq (unregistered) in reply to charon
    charon:
    For a class that has a value of either yes or no.

    Classes don't store values, their instances do (in properties).

    Static fields (not properties, not in Java) are stored in the class, and pointed to by the instances.

  • (cs) in reply to awfawefwfw
    awfawefwfw:
    Yeah, but it's a fluent interface. Therefore, it's good because it's the flavour of the moment.

    Looks more like an "effluent" interface to me...

  • Eryn (unregistered) in reply to brazzy
    brazzy:
    Anon:
    Java enums are allowed to be null, which destroys their usefulness as an enum. It's just like Java's "generics", it's just syntactic sugar, and ultimately worthless.
    Non sequitur. Just because something is similar to but doesn't work exactly like the corresponding construct in your favorite language does not make it worthless. Snytactic sugar most certainly isn't, or would you prefer your C without the [] operator (syntactic sugar for pointer arithmetics), without structs (syntactic sugar for multiple variables) and without methods (syntactic sugar for goto)?
    it's so sad to see so many Java bashers on this forum, i wonder where they all come from? You can accomplish something a million different ways, generics have their place, and just remember that J2SE5 incorporated generics from C#
  • JavaSucks (unregistered) in reply to Eryn
    Eryn:
    it's so sad to see so many Java bashers on this forum, i wonder where they all come from? You can accomplish something a million different ways, generics have their place, and just remember that J2SE5 incorporated generics from C#
    No, they didn't. Generics in C# are real generics. You can tell the difference between a C# List<int> and a C# List<long>.

    You can't even create a Java List<int>. Instead it becomes a List<Integer> at compile time and then a List at runtime because Java doesn't really support generics.

    If you want to see generics done right, look at C#. If you want to see generics turned into worthless syntactic sugar than can allow you to stick Booleans into a list of Strings simply by disabling warnings, look at Java.

Leave a comment on “Taking a Good Thing Too Far”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article