Exception Safety, Garbage Collection etc. (a.k.a. Why Does Java Suck So Bad?)

Interesting how java is the only language included in the title, but the slides have the opinion that C#, Ruby and Python all suck as well.<p>Seems like a cheap way to get upvotes.

The majority of the comments seem to be negative, yet many of them reflect a misunderstanding of RAII. I've argued the exact argument the author does many times before and got similar responses, it seems to be hard to convey the power of RAII to people who haven't practiced it before. The meaning of RAII is that you can tie a resource to the lifetime of an object, in an environment where the object gets destroyed deterministically. There are two practical uses: 1) You can hide the fact an object is holding a resource from users of the object. 2) You can leverage the power of objects within the language and apply it to resources. The part regarding languages allowing something that might look similar with syntactic sugar didn't convey it's message very well. The syntactic sugar other languages are introducing is great on its own, but it's inferior to the object based approach since it doesn't allow (1) nor (2). It's annoying that languages with garbage collection support have gained a lot of attention solely due to the fact that you don't have to worry about freeing memory, while languages with RAII support in which you basically don't have to <i>worry</i> about freeing any resource, got none.

Python's "with" statement handles this scenario: <a href="http://effbot.org/zone/python-with-statement.htm" rel="nofollow">http://effbot.org/zone/python-with-statement.htm</a>

...am I reading correctly that his argument for using C++/D (!) is that it's hard to remember to say this:<p><pre><code> try { mightFail(); } finally { doCleanup(); } </code></pre> instead of this:<p><pre><code> mightFail(); doCleanup();</code></pre>

<i>if PHP gets something right before your language does, you should reassess your life goals</i><p>:)

I am not super familiar with all the details of Java inner classes, but why can't you get most of the way there by doing something like:<p><pre><code> DB.open(new Runnable() { public void run() { // ... do stuff here ... } }); </code></pre> You can even design your resource layers such that they can only be used this way (or are easiest to use this way).<p>Basically, I'm just stealing the JavaScript-y way of doing this that uses closures:<p><pre><code> DB.open(function() { ... });</code></pre>

Also, Go gets this right with "defer", and with mostly deterministic error handling (panicking is not the normal way to signal an error, returning a status is).

High-performant, world-class C++ is fairly well understood (afaik) to only use a very limited subset of C++'s features (e.g., see the JSF Coding Standard or Google Style Guide or go work for a hedge fund where low latency and high reliability is important).<p>The same for Java. I honor all the exceptions in the standard/platform libraries. But I see past the hype for my own interfaces. Imho, 9/10 exception classes clutter the interface. 9/10 (again for high reliability, high quality code that you want to work reliably but also be flexible enough to extend), what you want to return is a boolean (and log) for stateful methods. Meanwhile prefer stateless methods wherever possible. And generally speaking treating the JVM and Java as basically a really really high performant scripting engine (i.e., closer to JS than C; though the syntax is somewhere in between). Imho, if you can't do RAII, and you're not deterministic, you are basically a scripting language (or are in the GC family of languages, if you don't like the term 'scripting' -- I think it's cool...).<p>Anyway, that's how I approach it. But I don't buy into the hype of exceptions most of the time (though of course I honor whatever contract other libraries use).

What you really want is something along the lines of:<p><pre><code> void myMethod() { disposable File myFile = new File(somePath); // ... do stuff with the file // "disposable" modifier causes myFile to be // forcibly destroyed upon leaving scope for any // reason (except if the disposable object itself // is returned from the method). } </code></pre> An idiom designed specifically for the purpose of resource management would make for a far cleaner implementation than shoehorning an existing mechanism.<p>You'd probably also need to add checking for references to the object by still-living objects (i.e. objects not eligible for gc). If any live object has a reference to the disposable object, its "disposable" status gets removed. Similarly, returning the disposable object from the method also strips its "disposable" status. It would add extra processing at the end of the scope level, but generally methods that create/use resources don't need to be lightning fast anyway.<p>You could even add the "disposable" modifier to class definitions, making all instances of that class disposable by default (and thus destroyed unless referenced or returned).

I think you can avoid nesting finally thus:<p><pre><code> X x = null; Y y = null; try{ x = foo(); y = bar(); yadda(x,y); } finally { if (x!=null) x.dispose(); if (y!=null) y.dispose(); }</code></pre>

The problem with this whole argument is that the author assumes that deterministic memory performance is completely necessary. It's certainly nice, but there are so many times when it just doesn't matter.<p>While I agree that Java sucks because it makes certain very common things require extreme verbosity, worrying about garbage collection isn't all that important except in systems-level programming (which isn't done in Java really), and large GUI that need tons of memory and still need responsiveness. But many people wouldn't even think to use Java in those cases anyways, so I'm not really sure what this guy's point is.

This fact has lead to the popularity of the springframework in Java. They use the template design pattern to hide all of the resource acquisition and release. This makes it much easier to code as you don't have to "remember" to close your db connections. The remember argument is somewhat weak because you still need to remember to write your destructor. I do buy that it's easier to remember it in one place than all over the code.

Non-slideshare link:<p><a href="http://docs.google.com/viewer?url=https%3A%2F%2Fs3.amazonaws.com%2Fppt-download%2Fraii-110506011720-phpapp01.pptx%3Fresponse-content-disposition%3Dattachment%26Signature%3D5lrdrqUoc6rD0E2fjI06%2FOHz4%2Fs%3D%26Expires%3D1304722818%26AWSAccessKeyId%3DAKIAJLJT267DEGKZDHEQ" rel="nofollow">http://docs.google.com/viewer?url=https%3A%2F%2Fs3.amazonaws...</a><p>Edit: Warning. Actually seems to cut off some of the slides.

In the Java example with three try/finally's, he calls 'dispose()' on a File. I've never seen this before, what does it do? Or did he just hallucinate that to make the example look more dramatic?