I know this is blasphemy in the Java world, but I'd probably use a preprocessor to transform some clean syntax into the normal Java code. I'd rather have the slight increase in build complexity over the potential issues with the extra classes and the breaking of assumption about how things compare and such.
Check out the Immutable Maps feature, does the same with some nice syntactic sugar - <a href="http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/ImmutableMap.Builder.html" rel="nofollow">http://docs.guava-libraries.googlecode.com/git/javadoc/com/g...</a>
I am no Java expert but they write that this syntax automatically creates a anonymous inner class - every time you create a collection instance in this way. Or am I wrong about this?<p>Most of the examples given are creating static objects but the last example a non-static object is created in the same way. Imagine you are doing this a couple of times then you end up with a lot of anonymous classes. Isn't there a limit on the number of classes you can have? At least it makes debugging problematic.<p>But I might be wrong about this since I am not a Java expert...
I consider this to be an antipattern, in part for some of the reasons listed in the article. The syntactic convenience being attempted here is more appropriately encapsulated as a utility method.
It can also make UI code much more readable, but it also comes with the cost of making the bytecode much larger (each use of the double-brace initialization creates a new class).
I had known of this before, and I'm fairly certain I've used it before. However, one thing I didn't consider is the equals issue commented on the site. As attractive as it may be to use, I think from now on I will refrain from using the double braces.