That is debatable, but in does have the effect of narrowing the scope
of a variable, which is general is a good thing.  I mention this not
to advocate strange looking code, but so that you will believe you
eyes when you see it.

From my reading the JVM virtual machine spec, that is not correct.
they are all allocated slots on method entry. The compiler could share
slots when it is safe, but the actual allocation is done as part of
the call to set up the stack frame which sets the base for allocating
parameters and local variables all on the stack.  When you call any
method you push parameters for it, then its return address and jump
the method.  It then allocates its locals by bumping the stack pointer
up enough slots to leave room.  

The only time this causes serious trouble is in recursion, because you
get a multiplier effect for every bit of padding in the local
variables.

At the JVM level,  the type of each variable in a local slot is fixed.
You could not use the slot for a reference then recycle it as an int.
Of course AOT or Hotspot can do that sort of optimisation so long as
the next effect is the same.

Those don't seem to be the same x.

Main.java:13: cannot find symbol
symbol  : variable x
location: class Main
                x = expression;
                ^
Main.java:18: cannot find symbol
symbol  : variable x
location: class Main
        System.out.println(x);
                           ^
2 errors

---------------------------------------------

class Main {
    public static void main(String[] args) {
        int expression = 42;

        switch(2) {
            case 1:
            {
                int x = expression;
                break;
            }
            case 2:
            {
                x = expression;
                break;
            }
        }

        System.out.println(x);

    }
}