• OutlawProgrammer (unregistered)

    Why would this have any effect on memory whatsoever? It literally does nothing.

  • (cs) in reply to OutlawProgrammer
    OutlawProgrammer:
    Why would this have any effect on memory whatsoever? It literally does nothing.

    Ah... now I get it. Thanks for pointing that out.

  • tim (unregistered) in reply to OutlawProgrammer
    OutlawProgrammer:
    Why would this have any effect on memory whatsoever? It literally does nothing.
    Of course it has an effect. It's code - it takes up memory.
  • (cs) in reply to OutlawProgrammer
    OutlawProgrammer:
    Why would this have any effect on memory whatsoever? It literally does nothing.
    It both increments *and* decrements the underlying object's reference count! You can hardly call that "nothing"!
  • Anon (unregistered) in reply to tim 
    public class Destruction {
    public static void delete(Object object){}
}

    Yaay optimisation!

  • (cs)

    Obviously the problem is that he forgot to call System.gc().

  • (cs) in reply to DaveK
    DaveK:
    OutlawProgrammer:
    Why would this have any effect on memory whatsoever? It literally does nothing.
    It both increments *and* decrements the underlying object's reference count! You can hardly call that "nothing"!

    Uses CPU time, too. Definitely not "nothing"!

  • Bryan The K (unregistered)

    public class Destruction { public static void delete(Object object){ object = null; } }

    I got it. He forgot to object ? null , right?

    CAPTCHA: erat - to remove a difficult programmer by force.

  • Medinoc (unregistered) in reply to Coyne

    And if the programmer relies on this function, it's probable that the original object reference will never be set to null (and so, the object never deleted).

  • (cs)

    You really haven't read about JIBE? That's Java Intention Based Execution. The compiler sees the intention of the programmer was to destruct the object, and will generate code to do so. Afterwards, all variables and fields pointing to this object will be null. I think it's time for y'all to upgrade and keep up with the literature.

  • javacoder (unregistered) in reply to DaveK

    it allow the object to be garbage collected.... it is still a WTF because a one liner should be done by the caller

  • wil (unregistered)

    Any Java compiler from 1.4 will optimize it away the first time this code is executed. So it would't consume any CPU nor additional memory

  • Mike Caron (unregistered)

    I bet this application used to be written in C++.

    Only problem is that it's missing a vector delete method!

  • gm (unregistered)

    Honestly, this is WTF-worthy?

  • Anonymously Yours (unregistered)

    I almost want to call this article a troll to get someone to say, "Java's the real WTF," and start a holy war...

  • Randy (unregistered)

    I'm guessing that he read somewhere that setting an object reference to null causes it to be reclaimed.

    Luckily, I've never had to worry about garbage collection with my applications. I let the VM do that for me.

  • SkittlesAreYum (unregistered) in reply to javacoder
    javacoder:
    it allow the object to be garbage collected.... it is still a WTF because a one liner should be done by the caller

    Yeah, not really.

  • epv (unregistered)

    The main reason it's a memory hog is that it's in Java. Bazing.

  • (cs) in reply to javacoder
    javacoder:
    it allow the object to be garbage collected.... it is still a WTF because a one liner should be done by the caller
    But the object won't be garbage-collected unless ALL outstanding references are set to null. And this only sets the (newly-created) reference to null. Even the caller's reference will still be non-null.
  • (cs) in reply to javacoder
    javacoder:
    it allow the object to be garbage collected.... it is still a WTF because a one liner should be done by the caller

    You know nulling objects to "help" the garbage collector is usually considered bad practice, right?

    http://www.ibm.com/developerworks/library/j-jtp01274.html

  • (cs) in reply to epv
    epv:
    The main reason it's a memory hog is that it's in Java. Bazing.
    The act before you with the anatomically-accurate balloon animals was better. In a depressing way.
  • (cs) in reply to javacoder
    javacoder:
    it allow the object to be garbage collected....

    No, it doesn't.

  • Goo (unregistered) in reply to gm
    gm:
    Honestly, this is WTF-worthy?

    It shows a complete lack of understanding of how the language works. It's as bad a smell as there is. It'd not surprise me if this came from the kind of place that reboots their application server once or twice a day to keep the memory footprint at bay.

  • pcooper (unregistered)

    Maybe the coder was used to VB, where parameters are sent ByRef by default?

  • Steve W (unregistered)

    I'm not a Java guru (despite having used it extensively) so I'll say what I think is going wrong here.

    First of all, he's obviously instantiated a class whose sole purpose is to delete other objects. If this isn't a singleton then it will be taking up a lot of memory if he's instantiating a new instance every time.

    Secondly, setting it to null doesn't help. Best let the garbage collector do things on its own. I can't remember Java's semantics for parameters but I think it's a local copy of the object which is being set to null and not the original memory reference.

  • Docta Jonez (unregistered)

    This one actually made me laugh. I've not seen a WTF that made me laugh in a while :-)

    Seriously though, this highlights just how poorly these concepts are dealt with on CS courses. I've met many developers who have a major lack of understanding about the "black magic" of garbage collection. Arbitrary null setting really drives me nuts.

    <rant> Seriously, if you have a memory problem in your application, run the damn thing through a profiler. Don't just start scatter-gunning null allocations throughout your code. </rant>

    Captcha: populus - Awesome game, 'nuff said!

  • Swedish tard (unregistered) in reply to gm
    gm:
    Honestly, this is WTF-worthy?

    Quite so. That code displays a rather big lack of knowledge how java handles parameters, and a blatant disregard for a bunch best practices regarding the language and OOP in general. It is rather hard to manage to get more things wrong in a single static method class in java tbh.

  • Mike D. (unregistered)

    This function has an upside: If it is consistently used, then there will be a distinct lack of heap fragmentation.

  • Jim (unregistered) in reply to Steve W
    Steve W:
    I'm not a Java guru (despite having used it extensively) so I'll say what I *think* is going wrong here.

    First of all, he's obviously instantiated a class whose sole purpose is to delete other objects. If this isn't a singleton then it will be taking up a lot of memory if he's instantiating a new instance every time.

    It's unlikely they are instantiating a new class since the method itself is static.
  • Patrick (unregistered) in reply to OutlawProgrammer
    OutlawProgrammer:
    Why would this have any effect on memory whatsoever? It literally does nothing.
    Simple. It makes a copy of the object passed to it (as it is passed by value), then doesn't use it. The allocated memory remains until the garbage collector kicks in, and by then more copies of other objects would have also appeared.
  • ShatteredArm (unregistered) in reply to Steve W
    Steve W:
    I'm not a Java guru (despite having used it extensively) so I'll say what I *think* is going wrong here.

    First of all, he's obviously instantiated a class whose sole purpose is to delete other objects. If this isn't a singleton then it will be taking up a lot of memory if he's instantiating a new instance every time.

    It's a static method. No instance needs to be created to call that method.

    Secondly, setting it to null doesn't help. Best let the garbage collector do things on its own. I can't remember Java's semantics for parameters but I think it's a local copy of the object which is being set to null and not the original memory reference.

    It's beside the point. It's not about whether it's better to let the GC do things on its own. The point is that it doesn't even do anything. Even if a forced removal of the reference were the way to go, this does not achieve that. The only reference to the object that is removed is the one on the stack that is used to pass the location of the object into the function. The original reference is left unaffected. This is not Java, it's just basic computer science.

  • (cs)

    You tell me over and over, we're on the eve of 

    Destruction
    .

  • (cs)

    TRWTF is that you commenters don't know how references work. No, it doesn't make a copy of the object. No, the variable reassignment doesn't bubble back to the caller. No, the garbage collector doesn't care.

  • (cs) in reply to Jim
    Jim:
    Steve W:
    I'm not a Java guru (despite having used it extensively) so I'll say what I *think* is going wrong here.

    First of all, he's obviously instantiated a class whose sole purpose is to delete other objects. If this isn't a singleton then it will be taking up a lot of memory if he's instantiating a new instance every time.

    It's unlikely they are instantiating a new class since the method itself is static.

    One can hope, but I have seen people make a class with all methods static and then create instance of this class and call the static methods from the instance variable.

  • Anon (unregistered) in reply to Steve W
    Steve W:
    I'm not a Java guru (despite having used it extensively) so I'll say what I *think* is going wrong here.

    First of all, he's obviously instantiated a class whose sole purpose is to delete other objects. If this isn't a singleton then it will be taking up a lot of memory if he's instantiating a new instance every time.

    No, the method is static.

    Secondly, setting it to null doesn't help. Best let the garbage collector do things on its own. I can't remember Java's semantics for parameters but I think it's a local copy of the object which is being set to null and not the original memory reference.

    Objects aren't "set to null", references (or pointers) to those objects are set to null. I think this is the fundamental misunderstanding that caused this code to be created in the first place.

  • (cs) in reply to Patrick
    Patrick:
    OutlawProgrammer:
    Why would this have any effect on memory whatsoever? It literally does nothing.
    Simple. It makes a copy of the object passed to it (as it is passed by value), then doesn't use it. The allocated memory remains until the garbage collector kicks in, and by then more copies of other objects would have also appeared.

    I think that is the whole purpose of the code. Create more garbage so that the garbage collection kicks in sooner.

  • Buffled (unregistered) in reply to frits
    frits:
    javacoder:
    it allow the object to be garbage collected.... it is still a WTF because a one liner should be done by the caller

    You know nulling objects to "help" the garbage collector is usually considered bad practice, right?

    http://www.ibm.com/developerworks/library/j-jtp01274.html

    Depending on the JVM. The Blackberry docs encourage it, for example. That being said, the way it was implemented here is literally worse than useless.

  • rwbthatisme (unregistered)

    obviously on an embedded system......

  • anonymous (unregistered)

    I grow tired of this conversation. Summon the dancing girls!

  • Anonymous (unregistered) in reply to anonymous
    anonymous:
    I grow tired of this conversation. Summon the dancing girls!
    Alright! Let's dance! [image]
  • Russ (unregistered) in reply to javacoder
    javacoder:
    it allow the object to be garbage collected.... it is still a WTF because a one liner should be done by the caller

    WRONG! Thank you for playing.

    It only internally to the routine sets the object to null. The routine that calls this would still have the original and untouched object.

  • OBL (unregistered) in reply to Anonymously Yours
    Anonymously Yours:
    I almost want to call this article a troll to get someone to say, "Java's the real WTF," and start a holy war...
    INFIDEL!!!!
  • nobody (unregistered) in reply to Xyro

    agreed.

    you guys call yourselves coders? rule 1. stfu if you don't know and don't try to pull it out of your ass. rule 2. it's not pass by value. go to rule 1.

  • Lunkwill (unregistered) in reply to Xyro
    Xyro:
    TRWTF is that you commenters don't know how references work.
    Indeed, seems about a third of those who feel qualified to comment on Java stuff don't have a farkin clue how the language works. I hope that's not representative of people actually using it. "Hope dies last", as they say...
    anonymous:
    I grow tired of this conversation. Summon the dancing girls!
    s/dancing/Irish/
  • gallier2 (unregistered) in reply to Patrick
    Patrick:
    OutlawProgrammer:
    Why would this have any effect on memory whatsoever? It literally does nothing.
    Simple. It makes a copy of the object passed to it (as it is passed by value), then doesn't use it. The allocated memory remains until the garbage collector kicks in, and by then more copies of other objects would have also appeared.

    As always, the WTF are in the comments, Java doesn't make a copy of the passed object, the reference to the object is passed by value, the reference is nulled, and the original reference of the caller is not modified.

    There was also a comment at the beginning which talked about the reference counter incremented and decremented, wrong!!! The function does nothing, it writes a 0 on the call stack, that's all.

  • Bob (unregistered) in reply to javacoder
    javacoder:
    it allow the object to be garbage collected.... it is still a WTF because a one liner should be done by the caller

    This is why this is a valid WTF! More comments from java experts please!

  • Dan (unregistered)

    Let's not forget that Java doesn't GC with reference counting; it uses mark and sweep.

  • Lunkwill (unregistered) in reply to nobody
    nobody:
    agreed.

    you guys call yourselves coders? rule 1. stfu if you don't know and don't try to pull it out of your ass. rule 2. it's not pass by value. go to rule 1.

    2. yes it is, think of primitive types. it's just that object types are references. go to rule 1.

  • Sanity (unregistered) in reply to frits
    frits:
    javacoder:
    it allow the object to be garbage collected.... it is still a WTF because a one liner should be done by the caller

    You know nulling objects to "help" the garbage collector is usually considered bad practice, right?

    http://www.ibm.com/developerworks/library/j-jtp01274.html

    Depends entirely on the situation. That page lists a perfectly legitimate case -- objects still technically reachable (part of an array, for instance) but which the program is done with.

    Of course, this only works if you're actually talking directly to the array. I suppose the person who wrote this wanted

    Destruction.delete(arr[i]);

    But of course, that does less than nothing. The method would only really work like this:

    Destruction.delete(arr, i);

    ...and that's specific to arrays, and also fairly useless.

  • (cs)

    My Favourite Java Destruction till now was a program that set all instance variables null ... in the finallizer ... "To help garbage collection"

    argh

Leave a comment on “Java Destruction”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article