Thank you for your replies!
Frankly, I hoped somebody will try DDJ to run and play… No matter.
I tried it with the toy examples and I may say I’ve got no complete opinion.
I think the tool may be useful for debugging recursive programs though it’s not the typical task for java.
I usually just use printlns for exceptions. for incorrect results i sometimes use breakpoints because printlns would fill the console up too fast
Yeah, like I said- it’s pretty hard to form an opinion without concrete examples and tutorials.
Also, I wonder why every forum’s answer to “what do you think of XYZ for ABC” type questions is to say “here’s how I do ABC” instead of talking about XYZ at all, haha…
System.out.println is love , System.out.println is life.
While all this love for printlns is cute and all. Refusing to utilize a debugger is just short sighted (being polite :P).
It’s so much faster to hit a break point and evaluate some expressions in that frame to see whats wrong, than to uglify the code with printlns just to realizing that you miss one and start again…
There is a huge plus to println, though. It provides you with a log, a history if you will.
With breakpoints there is merely the current state. If you end up in this broken state, there is no way to trace your steps. With println you can… scroll up, use search, etc.
Therefore, I hereby present you with the ultimate debugging tool: the unholy println/debugger hybrid. :point:
It has been SPOKEN
You can actually do logging breakpoints, evaluating expressions in that log, hold on them conditionally and investigate all frames on the callstack, inspect variables there and evaluate expressions in their context…
Again, nothing against println, but such a powerfull tool like a debugger should not be ignored…
So… yeah… System.out.println is just fine 
;D
I also use system print quite a lot, but mine is tucked away in a Logger class so I can disable messages without having to look through them all and comment them out. I use a hashmap that has name as key and boolean as value, I then print using the respected debugging type and can disable whatever ones I don’t want.
If that makes sense lol. Allows me to say, disable debugging for asset loading but enable it for character generation, without changing any lines.
Sometimes it’s not enough power of both logging and debugging tools.
Recently I just drowned under the tons of logs and no longer was able to realize what’s going on with my code, so I had to write the visualization tool.
It really helped me and, fortunately, it is the part of the production code. 
Writing custom visualization tools is great, if time consuming sometimes.
I have a dinky little latency “caliper” if anyone is interested:
Some other people encourage these tools as well: http://www.infoq.com/presentations/visualization-driven-development
Lately I’ve been using java.util.logging :persecutioncomplex:
LOGGER.finest(() -> "And this is only evaluated when the log level is actually set to "+Level.FINEST+" so it doesn't waste cycles!");
With lambdas and a bit o’ static import it’s rather nice. Also nice is that with the twiddle of a configuration file I can have everything suddenly logging stuff to a database or to syslog.
Cas
Reminds me, I came across this interesting little snippet in the NetBeans code while debugging something a while back
LogLevel l = Level.FINE;
assert (l = Level.INFO) != null;
Who needs conf files? :persecutioncomplex:
btw, @princec unless lambdas change argument evaluation, aren’t you wasting cycles doing String concatenation in your example? :emo:
That’s exactly how lambdas work here: the lambda function is not actually evaluated if the logger discards the message. It’s no different to how you could code it with an anonymous inner class implementation of the Supplier interface, but it does look a lot neater.
Cas
Doh! Edited post ^. Not been able to work much with Java 8 yet - so used to being careful about that in the logging methods that take String - addition of Supplier is neat!
Exactly, don’t forget me