Anonymous code blocks in Java

Question

Are there any practical uses of anonymous code blocks in Java?

public static void main(String[] args) {     // in     {         // out     } } 

Please note that this is not about named blocks, i.e.

name: {       if ( /* something */ )           break name; } 

.

Answer 1

They restrict variable scope.

public void foo() {     {         int i = 10;     }     System.out.println(i); // Won't compile. } 

In practice, though, if you find yourself using such a code block that's probably a sign that you want to refactor that block out to a method.

Answer 2

@David Seiler's answer is right, but I would contend that code blocks are very useful and should be used frequently and don't necessarily indicate the need to factor out into a method. I find they are particularly useful for constructing Swing Component trees, e.g:

JPanel mainPanel = new JPanel(new BorderLayout()); {     JLabel centerLabel = new JLabel();     centerLabel.setText("Hello World");     mainPanel.add(centerLabel, BorderLayout.CENTER); } {     JPanel southPanel = new JPanel(new FlowLayout(FlowLayout.LEFT, 0,0));     {         JLabel label1 = new JLabel();         label1.setText("Hello");         southPanel.add(label1);     }     {         JLabel label2 = new JLabel();         label2.setText("World");         southPanel.add(label2);     }     mainPanel.add(southPanel, BorderLayout.SOUTH); } 

Not only do the code blocks limit the scope of variables as tightly as possible (which is always good, especially when dealing with mutable state and non-final variables), but they also illustrate the component hierarchy much in the way as XML / HTML making the code easier to read, write and maintain.

My issue with factoring out each component instantiation into a method is that

1. The method will only be used once yet exposed to a wider audience, even if it is a private instance method.
2. It's harder to read, imagining a deeper more complex component tree, you'd have to drill down to find the code you're interested, and then loose visual context.

In this Swing example, I find that when complexity really does grow beyond manageability it indicates that it's time to factor out a branch of the tree into a new class rather than a bunch of small methods.