Java optimization



  • Not bitching too much about Java and XML being TRWTF, I'd like to present you the most curiously behaving code I've ever seen. Short intro: SomeSystem has a servlet, which serves HTTP requests. I got from my coworker some classes written by him, which helped me to extract message from that request. I tried it, and it worked great. I added some logging, and it stopped working. I removed logging statements, and it startet working again. I stepped by servlet handler with a debugger, and it stopped working. I moved breakpoints from one line to another and back and forth, and sometimes it worked, and sometimes not. "Watch" window displayed me the contents of received message, but sometimes handler insisted telling me, that message contents are empty. So, looked at sources of library given to me, and found something like this (for nitpickers: presented code sample might not be exact):

    class Message {
    
    	String subject;
    	Date sendDate;
    	byte[] content;
    
    	//blah blah blah....
    
    
    	String getSubject() {return subject;}
    	
    	byte[]  getContent() {
    
    		//OPTIMIZATION
    		//Once retrieved content should be processed immediately and is not needed anymore.
    		//Let's free it to decrease memory usage.
    		byte[]  tmp = content;
    		content = null;
    		return tmp;
    	}	
    
    	//blah blah blah...
    
    	String toString() {
    		return Formatter.prettyPrint(getSubject(), getSendDate(), getContent());
    	}
    }
    


  • So the debugger and logger wasn't as unintrusive as expected, what's next?



  • I think this is a great counter to the idiots who loudly proclaim that properties are evil because they have the potential to cause unexpected side-effects.  It's every bit as easy to do with regular methods.



  • TRWTF is that Java doesn't have explicit syntax for references.



  • @lolwtf said:

    TRWTF is that Java doesn't have explicit syntax for references.

    Because you spend more time passing around and operating on copies of objects than the objects themselves.



  • @Aaron said:

    I think this is a great counter to the idiots who loudly proclaim that properties are evil because they have the potential to cause unexpected side-effects.  It's every bit as easy to do with regular methods.

    Functional programming for the win?



  • @henke37 said:

    So the debugger and logger wasn't as unintrusive as expected, what's next?

    I suspect he was doing something like logger.write(msg.getContent()); after which the content was empty when the servlet tried to actually use it. Dunno about the debugger, I have no idea if java debuggers usually call methods.



  • @tdb said:

    Dunno about the debugger, I have no idea if java debuggers usually call methods.

    Usually they do not, but they usually seem to call toString to show object variable value in Watch window, or inside of a tooltip when you hover your mouse over variable name when debugging.
    Other than that, some debuggers allow you to create formatters for types and variables, and these usually can call methods of observed object. In this case you have to be aware of side effects when defining one.

    Personally I am not impessed by getter with rather serious side effect, but toString changing contents of the object - this is truely awesome.



  • Ah, the ever-popular now-you-see-it-now-you-don't pattern.

    (Of course, the actual problem is the unexpected side-effect not being reflected by the method name.  If it'd been named getAndResetContent(), the person who wrote the toString() implementation would've noticed the problem.  Although I'm sure this whole "optimization" was a kluge implemented by some lazy coder precisely so that they wouldn't have to modify whatever code normally calls getContent().)


Log in to reply