• (cs) in reply to ShatteredArm
    ShatteredArm:
    Matt Westwood:
    Design Pattern:
    Kirill S.:
    "primative types" you say? You really should consult Primate Programming(tm) Inc about those.

    Most primates do not program in Java, but prefer Ook instead.

    Don't have the time or patience to check this at the moment (busy writing a thesis about indiscrete spaces) - is Ook Turing complete? If so, has anyone told pterry about it?

    The third paragraph on the Ook website:

    If you are familiar with BrainF*** you can skip straight to the syntax elements section. Note that since Ook! is trivially isomorphic to BrainF***, it is well-established that Ook! is a Turing-complete programming language.

    Oops, sorry, du-uh. Never mind ...

  • Anon (unregistered)

    If you're really disgruntled and want to cause headaches for your replacement, just write the app in LabVIEW.

  • Boogie (unregistered) in reply to minim
    minim:
                field.setInt( 
                Integer.valueOf(i),
                // either the same (90%), +1 (1%), or 42 (9%)
                Math.random() < 0.9 ? i : Math.random() < 0.1 ? 42 : i+1  );

    FTFY

    Well that must have been embarassing.... how does "< 0.1" happen 90% of the time?

  • IGotNuthin (unregistered)

    Why -127..128? Shouldn't that be -128..127?

    Did that in an interview. Repeatedly. While stubornly resisting all hints to the contrary. :(

  • (cs) in reply to Intruso

    I have to say, it would be an interesting challenge to try to come up with a program the does something both useful and predictable, that includes this sort of transformation! To 'interesting' for me to try though.

  • Mick (unregistered)

    This has to be embedded deep in Diebold's software...it's the only explanation...

  • UserK (unregistered)

    I'm fairly impressed! I mean, I see a lot of bad things around here but this is over the edge.

  • Just another coder (unregistered)

    But that is a great teaching device: how to debug spurious interaction. Have to put this to a debugging exercise in a programming class.

  • it's not the 2nd degree, it's just you (unregistered)

    Yes yes, this is all great. What my boss wants to know is "Will this make my system run much much faster?". I promised him 90% improved performance.

  • Pierre (unregistered)

    The total could also be 42 + (3 + 1) = 46

  • Dave (unregistered)

    Hah - that comment is wrong. The actual probabilities are:

    • 90% the same
    • 9.5% i + 1
    • 0.5% 42
    100%

    -1 for a comment that incorrectly describes what the code is doing. That's why I don't leave comments ;-)

  • (cs) in reply to minim
    minim:
    // either the same (90%), +1 (1%), or 42 (9%)
    FTFY
    Failed That For You?

    As others have mentioned - the same 90% of the time, i+1 9% of the time, 42 1% of the time.

    Dave:
    Hah - that comment is wrong. The actual probabilities are:
    • 90% the same
    • 9.5% i + 1
    • 0.5% 42
    100%

    -1 for a comment that incorrectly describes what the code is doing. That's why I don't leave comments ;-)

    You shouldn't have left this comment either.

  • v6ak (unregistered)

    I've written something more WTFy :) : https://gist.github.com/988502

  • Frederik (unregistered)

    Not entirely sure, but I think that if you add the following code to the class, it will auto-start:

    static {
    (new ValueMunger()).run();
}
  • Frederik (unregistered) in reply to Frederik
    Frederik:
    Not entirely sure, but I think that if you add the following code to the class, it will auto-start: 
    static {
    (new ValueMunger()).run();
}

    Hmm, that should be (new ValueMunger()).start(); Gotta love those static blocks!

  • Design Pattern (unregistered) in reply to v6ak
    v6ak:
    I've written something more WTFy :) : https://gist.github.com/988502
    +1 for presenting the WTF in concise code ;-) +1 for running the munge in it's own thread

    -1 for not hiding the call to intValue in some implicit conversion. -1 for not using some of the more advanced language features like Actors and pattern matching

  • npo (unregistered)

    Try the Console.Beep function in VB...

  • Bernhardus (unregistered)

    I was a bit skeptical at first, but this code is pretty clever and should actually work!

    The static valueOf() method of the Integer class often returns cached Integer objects that represent frequently requested values. I do believe that the code above will only work when the valueOf() method is actually used. This is not unlikely, however, since auto-boxing operations (like inserting an integer into an ArrayList) insert calls to this method implicitly.

    The fact that valueOf() returns values that are used elsewhere in the program is okay under normal circumstances, since Integer objects are immutable (they cannot be changed), so an Integer representing the value 5 will always have the value 5 throughout its entire lifetime.

    However, the line "field.setAccessible(true)" circumvents this and enables us to change the value of a cached Integer object.

    Very clever indeed!

  • sdfasdf (unregistered)

    Ha! I fixed one of these. We've got a Currency class hanging around in the app since the jdk1.1 days. Some bright spark decided to make it mutable and some even brighter spark decided to use said mutators to change the value of Currency.ZERO.

  • sdfasdf (unregistered)

    Ha! I fixed one of these. We've got a Currency class hanging around in the app since the jdk1.1 days. Some bright spark decided to make it mutable and some even brighter spark decided to use said mutators to change the value of Currency.ZERO.

  • Meep (unregistered)

    Finally was irritated enough by people fucking this up repeatedly:

    Math.random() < 0.9 ? i : Math.random() < 0.1 ? 42 : i+1  );

    By Monte Carlo simulation, after a million rounds, it is:

    i 89.9694% 42 1.0095% and i+1 9.0211%

  • Deathstroke (unregistered)

    The single worst time I think any coder has is debugging an intermittent issue. This will certainly cause that, since every execution (which occurs once-a-second) will mess up the system in a different way.

    One suggestion for a conceptual improvement I have, if you really want to drive a developer nuts; make the call to ValueMunger.run() (and, look CLOSELY; it IS "run()") randomly do nothing (say a 70-80% chance). That way, the code is stable enough that there's a chance it would make it through Q.A. into the field.

    Wow... I always thought it was just physicists who were trying to make a bigger-and-better bomb with the intent it would never be used. Does that make me a physicist?

  • Jay (unregistered)

    Brillant!

    Though I think it would be a little better if it would run, say, once a day, leave the values messed up for 10 minutes, and then put them back.

    That way the user would complain, but when the programmer came along to test it, everything would probably work correctly. Bugs that can't be reproduced are very difficult to track down.

  • v6ak (unregistered) in reply to Design Pattern

    OK, I've updated it. It is still at https://gist.github.com/988502 .

  • John (unregistered)

    Its like FORTRAN IV all over again.

  • Nathan Friedly (unregistered)

    Those totals come up to 101%, I believe the +1 only happens 9% of the time.

  • Raw (unregistered)

    This one could easily be made much, much more annoying by adding a check so that it only runs in a release build, not in debug mode. Then, everything runs just fine in the IDE, then when you deploy it, things go bananas.

  • (cs) in reply to Raw

    I tend to avoid all non-beverage, non-island forms of Java.

    So can someone tell me why on earth the computer language by that name needs to cache values of an integer? Shouldn't those be completely invariant? (Or, to be more precise, Integer, because, apparently, they are different things. I still don't quite understand that concept despite my best efforts.)

  • Ouch! (unregistered) in reply to too_many_usernames
    too_many_usernames:
    I tend to avoid all non-beverage, non-island forms of Java.

    So can someone tell me why on earth the computer language by that name needs to cache values of an integer? Shouldn't those be completely invariant? (Or, to be more precise, Integer, because, apparently, they are different things. I still don't quite understand that concept despite my best efforts.)

    It doesn't need to cache Integers, they just decided to do it because: With a cache of frequently used Integer objects, it is not necessary to allocate a new object every time one is requested. Saving these allocations - and consequently some garbage collection - apparently improves performance.

  • (cs) in reply to Ouch!
    Ouch!:
    It doesn't need to cache Integers, they just decided to do it because: With a cache of frequently used Integer objects, it is not necessary to allocate a new object every time one is requested. Saving these allocations - and consequently some garbage collection - apparently improves performance.
    I can't seem to wrap my head around the idea of "integer objects" here, or why they would need to be cached in this manner. The closest thing I can think of is an "integer viewer" class that contains information about things like localization or whatever is needed to represent a mathematical integer value in some other format, but I can't think of any reason why you would include a specific integer value in that type of allocation.

    This tidbit does not do much to improve my impression of the Java language. I would go so far as to say that there is something fundamentally erroneous with a computer system where the meaning of integer values is or can be mutable.

    (Maybe all those assert(0 == 0) lines have some legitimate use after all!)

  • Just some guy (unregistered) in reply to too_many_usernames
    too_many_usernames:
    Ouch!:
    It doesn't need to cache Integers, they just decided to do it because: With a cache of frequently used Integer objects, it is not necessary to allocate a new object every time one is requested. Saving these allocations - and consequently some garbage collection - apparently improves performance.
    I can't seem to wrap my head around the idea of "integer objects" here, or why they would need to be cached in this manner. The closest thing I can think of is an "integer viewer" class that contains information about things like localization or whatever is needed to represent a mathematical integer value in some other format, but I can't think of any reason why you would include a specific integer value in that type of allocation.

    This tidbit does not do much to improve my impression of the Java language. I would go so far as to say that there is something fundamentally erroneous with a computer system where the meaning of integer values is or can be mutable.

    (Maybe all those assert(0 == 0) lines have some legitimate use after all!)

    There is a distinction in Java between the atomic primitive of type 'int' and the object class of type Integer. An int is an int, it's not redefineable, and it behaves the way you'd expect an int to behave. Integer is a wrapper class with an int as one of its member fields, and the value of that member field can be changed. This code does not affect math with ints, nor methods that take only ints as parameters, only those that (implicitly or explicity) convert an int primitive to an Integer Object.

    This may be done to get at various methods defined in the Class(utility classes to manipulate the number bitwise, express the integer in different formats, such as hexadecimal or octal,and so forth), or to easily allow an integer to be passed by reference where that behavior is desired. Once this is the case, Integer objects are cached like any other object.

  • (cs)

    TRWTF is "give programmers enough rope to shoot themselves"

  • (cs) in reply to Just some guy
    Just some guy:
    There is a distinction in Java between the atomic primitive of type 'int' and the object class of type Integer. An int is an int, it's not redefineable, and it behaves the way you'd expect an int to behave. Integer is a wrapper class with an int as one of its member fields, and the value of that member field can be changed. This code does not affect math with ints, nor methods that take only ints as parameters, only those that (implicitly or explicity) convert an int primitive to an Integer Object.

    This may be done to get at various methods defined in the Class(utility classes to manipulate the number bitwise, express the integer in different formats, such as hexadecimal or octal,and so forth), or to easily allow an integer to be passed by reference where that behavior is desired. Once this is the case, Integer objects are cached like any other object.

    Yes, I understand about the distinction between int and Integer. What I don't understand is why the Integer class is implemented in a way (or the language constructed in a way) that allows a side effect to change the value of the member int.

    There is a serious problem with a construct that claims to convert an int to an Integer object where the int-value of that Integer object is not guaranteed to be the value of the int from which it originated, mostly because of the connotation of the name Integer.

  • Anon (unregistered) in reply to too_many_usernames

    It's not supposed to be accessible. But the setAccessible(...) method makes it accessible.

    They should've installed a SecurityManager to prevent that field from being accessible...

  • (cs) in reply to Anon
    Anon:
    It's not supposed to be accessible. But the setAccessible(...) method makes it accessible.

    They should've installed a SecurityManager to prevent that field from being accessible...

    Why is it even possible to change the permissions on a member? What type of programming tasks was this feature trying to address?

  • Martijn Verburg (unregistered)

    Ahhh lovely stuff, Dr Heinz Kabbutz recently took an audience at Geecon through a masterclass in this sort of Java munging. 1/2 of the audience was mesmerised, the other 1/2 were weeping in terror :D

  • Harshal (unregistered)

    Its great Ba.. I will add this for next release

  • Yogesh (unregistered) in reply to Harshal

    Are you Harshal Gawande?

  • Orclev (unregistered)

    Two things. First, as several people have mentioned, it's not a primitive, it's a boxed object, so if you're using int you're probably safe for the most part. Second, this code would only work on signed or trusted code, so if you tried to do this in for instance an applet (I know, who even uses those anymore, oh the stories I could tell), it would throw an exception on the call to "field.setAccessible( true );".

  • Arren (unregistered)

    Probably won't work, value is final, and even reflection can't edit final fields. But you can modify IntegerCache.cache.

  • Lacrymology (unregistered)

    Does somebody care to explain this code and why does it work for non-.net programmers? how can you change the value of ints?

  • tom (unregistered)

    Now, this is just plain evil. Just set this up to fire after some time in order to pass all tests and get it into production code.

  • Holger (unregistered)

    Best way to detect is to install a SecurityManager. Even without, setAccessible(true) should ring alarm bells…

  • Holger (unregistered) in reply to too_many_usernames

    It exists so persistence managers and debugging tools can do their work.

  • annon (unregistered)

    The main Achilles heel is that it effects the code base immediately, which makes it trivial to detect. To avoid this you should consider making it a scheduled event. Preferably several days after start with random factors. Also consider restoring the original state after a certain amount of time. This way it can be turned into a quasi-Heisenbug.

  • Emeth (unregistered)
    Comment held for moderation.
  • Emeth (unregistered)

    Is this still working on modern Java (e.g., JDK 11)?

    I'm trying to have it working but it sticks on 5, even if the a+b part is put in a while.

Leave a comment on “Disgruntled Bomb: Java Edition”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article