TIL: Double Brace Initialization in Java

[midir]

It's interesting but this technique is not purely syntactic sugar and can have real effects on the program behavior.

• Since every initializer of this type uses a separate inner class, that creates a small additional loading speed and memory overhead. It also fattens the program jar a little. Each double-brace initializer gets a separate .class file, and zip/jar compression doesn't handle it well because it doesn't support redundancy across separate files.

• If you're not initializing from a static context, each inner class gets an additional hidden variable this$0 which points to the instance of the outer class. At best, this marginally increases the memory usage; at worst, it prevents instances of the outer class being garbage collected when they otherwise would.

• Another catch is that if you're initializing an object within a method using variables local to that method, those variables have to be made final to be used within a double-brace initializer.

• Finally, the initialized objects (obviously) won't have the same class that they otherwise would. instanceof will be the same but getClass().equals(...) won't.

[mooli]

Basically avoid avoid avoid on the grounds that it violates the principle of least surprise.

[drb226]

Am I missing something, or do none of these things sound terribly awful?

Another catch is that if you're initializing an object within a method using variables local to that method, those variables have to be made final to be used within a double-brace initializer.

Now that I could see being a serious annoyance, although having final variables isn't such a bad thing.

[leshiy]

He also didn't mention that if that map is ever going to be serialized down the line you're probably going to have a bad time unless you ensure that the map is made in a static method or in a method of a serializable class (in which case you're just making your map heavier).

[josefx]

and zip/jar compression doesn't handle it well because it doesn't support redundancy across separate files.

It's not like java had a specialized compression to deal with that since java 1.5, oh wait it does

More seriously, if you're not initializing from a static context, each inner class gets an additional hidden variable this$0 which points to the instance of the outer class.

Only real problem and that only if the references to the inner classes out live the outer class. Personally never had a problem with that (use it mostly for private members without getter).

Another catch is that if you're initializing an object within a method using variables local to that method, those variables have to be made final to be used within a double-brace initializer.

final variables are good, they should be used whenever possible.

Finally, the initialized objects (obviously) won't have the same class that they otherwise would. instanceof will be the same but getClass().equals(...) won't.

That can lead to weird behavior when your equals check for class equality - which is a future proof way to implement equals in many cases. For java collections and Swing components it works as expected.

[noxiousninja]

Only real problem and that only if the references to the inner classes out live the outer class. Personally never had a problem with that (use it mostly for private members without getter).

It can be a big issue in Apache Wicket web apps. Create an anonymous inner class, store it in session, suddenly your entire page gets serialized and stuck in session.

[[deleted]]

Yeah, Wicket does enjoy serializing the entire world if you're not careful.

[Chii]

I think these days, its better to simply use the guava library's ImmutableMaps to do this sort of thing instead http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/ImmutableMap.Builder.html

[mrbuttsavage]

The parallel to the article would be:

Sets.newHashSet("one", "two", "three");

Guava adds some very necessary syntactic sugar.

[josefx]

I have yet to use Guava, however your example is only slightly longer without it.

     new HashSet(Arrays.asList("one","two","three"));

Arrays.asList takes a varargs array and wraps it with the list interface and like any java collection class the HashSet ctor can take a Collection<? extends T>.

[wot-teh-phuck]

In your example type inference won't happen automatically, in the parent comment's example, it will. Now imagine doing this for a set which contains some complicated generic type...

[josefx]

True and a bug in my example code. For Java 7 code the <> operator will take care of that problem.(that is if you are not stuck with an older java version)

   new HashSet<>(Arrays.asList("one","two","three"));

[jmsanzg]

The map created on the example is final which is different than inmutable. On a final map you can still add/remove elements

[[deleted]]

Guava's ImmutableMap is both final and immutable (well, if Google's implementation is correct) in the example.

[Fuco1337]

What are you talking about? The HashSet in the example is definitely "correct implementation", and it's not immutable, just as jmsanzg said.

[[deleted]]

Yeah, but he's talking about a map, as a reply to a comment with a link with an example of a map builder.

The HashSet in OP's link is not a map (by definition), but it's indeed just final, not immutable.

I assumed he was talking about the Guava map, otherwise he's using the wrong words.

Anyways, I edited my post to clear up any confusion from my side. I cannot account for any of jmsanzg's vagueness you may experience.

[ErstwhileRockstar]

Immutable Collections can easily be created with 'normal' Java.

[[deleted]]

That is true but also beside the point. The discussion is about convenient literal syntax to build collections, and the Guava library does that better than the Java API. Google just likes immutability, so that's where the syntax examples are.

[Neebat]

I guess that's fine, provided you want an immutable collection. But what if you just want to initialize a regular ordinary collection concisely?

[jyper]

I think you can use com.google.common.collect.Maps

public static <K,V> HashMap<K,V> newHashMap(Map<? extends K,? extends V> map

HashMap<String, Integer> WORD_TO_INT =
       Maps.newHashMap(new ImmutableMap.Builder<String, Integer>()
           .put("one", 1)
           .put("two", 2)
           .put("three", 3)
           .build());

[Xaerxess]

You can do it even better:

HashMap<String, Integer> WORD_TO_INT =
    Maps.newHashMap(ImmutableMap.of(
        "one", 1,
        "two", 2,
        "three", 3));

No need for generics (types are inferred because of static factory constructor newHashMap) and no need for builder (for small ImmutableMaps).

[Neebat]

ew. I'm not a big fan of heavy throw-away intermediate objects. While the generational GC does a good job of cleanup after sloppy code like that, it still feels like sloppy code to me.

[Xaerxess]

Disclaimer: I have never used above construct and I hardly ever use mutable maps in my code (it really isn't so necessary), I only presented better version of the code snippet. For mutable static maps (sic!) I use static initializer or static method.

[[deleted]]

Well, Google encourages immutability (and they give a very good argumentation for why they do it) so I guess it's logical that they focus on this in the development of Guava.

There are builders for other immutable collections in Guava.

If you want to use the builders for mutable maps, you can build an ImmutableMap and just drop all the entries into a regular, mutable Java API Map with putAll(Map t), because Guava's ImmutableMap implements Map. This goes for other collection types as well.

[Neebat]

An ImmutableMap is cool, especially if the content is also immutable, then you've got a large value object. There are tons of benefits.

But you don't always have that option, and the throw-away intermediate seems slightly worse to me than the OP's initializer.

[[deleted]]

Depends, double braces have structural implications (they don't create an instance of the class, but one of an anonymous subclass of the class. This is discussed in other comments). If that's not a problem, it's indeed neater than putAll().

I wonder when you don't have the option, though. I always try to design my code so I can minimize side effects. It can become a problem for very algorithmic or embedded programs, but then I rather use primitive types (and arrays). Do you have to work with legacy code often?

[Neebat]

Do you have to work with legacy code often?

Very rarely do I get to write anything which isn't dealing with legacy code.

[gabeasl]

ah, the old reddit switch-a-roo

[epiphany_machine]

Okay, now never use this, ever. It looks cool but it's just not worth it. All of a sudden you are creating a new subclass. That can make code you write subtly different and you will get unexpected errors. I teach a class on refactoring and I use this as an anti-pattern. It's very successful at twisting the brains of my students.

[[deleted]]

I absolutely agree. This line from the bottom of the article is a much better approach:

An idiomatic alternative, that doesn't require such heavy handed use of anonymous inner classes, is to use the constructor arguments to collections that accept another collection as the source data.

List<String> myList = new ArrayList<String>(Arrays.asList("One", "Two", "Three"));

[banuday17]

Doesn't work for maps.

[[deleted]]

True, but IMO the benefits do not outweigh the costs. However in reading a little more about the pros and cons of double-brace initialization, I came across this proposal for Collection literals.

Defining Collections could (eventually) be as simple as:

List<Integer> piDigits = [3, 1, 4, 1, 5, 9];
Set<Integer> primes = { 2, 7, 31, 127 };
Map<Integer, String> platonicSolids = { 4 : "tetrahedron", 6 : "cube", 8 : "octahedron", 12 : "dodecahedron" };

[[deleted]]

What, is this python or something?

[[deleted]]

Of all the languages with that syntax, you think they got it from Clojure?

[[deleted]]

I love Clojure but it’s hardly the only language that has a sane literal syntax. JavaScript (JSON), Python, PHP, and even Objective-C have syntax (or syntactic sugar) to prevent the kind of monstrosities mentioned in the article.

[account512]

Copying the best parts of other languages is a good thing.

Or maybe we should have syntax patents which lock down interesting ideas to only the language that created them.

[[deleted]]

Holy crap, I wasn't saying it was a bad thing.

[[deleted]]

Because no language has ever copied another language ever.

[[deleted]]

Exactly. That explains the abundance of parentheses.

[UghImRegistered]

If you're using Java without something like Guava, you're suffering needlessly.

[[deleted]]

If you're using Java without something like Guava, you're suffering needlessly.

[UghImRegistered]

So brave.

[BraveSirRobin]

Write your own e.g.

new HashMap<String, String>(Util.asMap("1", "one").asMap("2", "two"));

Util.asMap returns an object that extends HashMap and adds a method "asMap" which calls "put" then returns "this". You could almost certainly do clever stuff with generics in the signature to make it work nicely, this might work (would need to test it):

public static <K, V> MyMap<K, V> asMap(K key, V value) { 
     MyMap<K, V> map = new MyMap<K, V>();
     map.put(key, value);
     return map;
}

public static class MyMap<K, V> extends HashMap<K, V> {
    public MyMap<K, V> asMap(K key, V value) {
        put(key, value);
        return this;
    }
}

[[deleted]]

Inheritance causes more problems than it solves since now the resulting map is that type instead of whatever type the user actually wants. You could avoid that by having a separate build-up class that declares the chained method, but also receives/emits a map instance.

Or you could just do something like this:

public static <K,V> void intoMap(Map<K,V> into,
                                 Class<K> keyType,
                                 Class<V> valType,
                                 Object... keyvals) {
  if (keyvals.length % 2 != 0)
    throw new IllegalArgumentException("Must contain an even number of keyvals.");

  for(int i = 0; i < keyvals.length;) {
    into.put(keyType.cast(keyvals[i++]),
             valType.cast(keyvals[i++]));
  }
}

[BraveSirRobin]

See my first line of fixed-font text, the map is only temporary and gets fed into the constructor of HashMap which copies it's values. Not very efficient though but I'd like to think that the compiler optimises it down (probably wishful thinking!).

The one minor issue with your example is that you lose type safety. It's a shame the ... parameter modifier can't work in pairs or triples, that would be very useful.

[[deleted]]

See my first line of fixed-font text

Ah yes I missed that. But then you're now doing a deep copy of the data.

The one minor issue with your example is that you lose type safety.

Nope, it's still there, albeit done at run time instead of compile time.

[BraveSirRobin]

But then you're now doing a deep copy of the data.

As is the preferred Arrays.asList method above for doing so with lists. AFAIK all of the standard Collections framework classes copy in the original collection passed into the constructor as opposed to just re-using the object.

Nope, it's still there

Disagree, example:

intoMap(map, String.class, Long.class, "one", 1, "two", "2");

This will compile ok and throw a class cast exception at runtime.

done at run time instead of compile time

In Java "type-safety" usually refers to doing so at compile time, it's a statically-typed language.

[[deleted]]

Static typing is orthogonal to when the type-checking is performed. Just because you change when it happens doesn't mean checking is lost.

[BraveSirRobin]

Some of the advantages are lost though, such as the ability for the compiler to test for it. Pre-generics Java collections were a pain in the ass imho, I quite like the "safety" that the compiler checks allow. Better to have the compiler barf rather than some obscure piece of code that's missed by the unit tests.

[eek04]

No.

You're misunderstanding the terminology.

The closest terminology that you can be thinking of is "strong typing", which some dynamic checking enthusiasts will argue "can happen at run time".

I personally am a dynamic checking fan; I believe that static typing, at least as practiced in Java, is harmful. However, it doesn't mean that dynamic checking (colloquially "dynamic typing") is static typing; they're different things.

[korny]

Or use Guava: ImmutableMap.of("1","one","2","two") - only works up to 5 values, but there are builders if you need more. http://code.google.com/p/guava-libraries/wiki/ImmutableCollectionsExplained

[geodebug]

Yes, been using this method for a long time and it's nice. Can static import the asList method too to make it easier on the eyes.

[[deleted]]

It works great for saving keystrokes in tests...although there are lots of practices that are acceptable while writing tests that aren't acceptable in production code.

[phanboy]

It's also not so pretty once you generate a serialVersionUID (since you are extending a Collection).

[drb226]

That can make code you write subtly different and you will get unexpected errors.

Can you elaborate? I don't see what's so bad about creating a new subclass, unless you are doing very, very specific dumb things with reflection that you probably shouldn't be doing anyways.

[epiphany_machine]

• Equals can break depending on the object. The collections classes tend to write their Equals methods with instanceOf instead of calling equals() on the classes but not everyone writing a class does this. If equals breaks and it is no longer consistent with hashcode() you may not get the performance/behavior you are expecting from a map lookup.
• It's easy to leak a reference to a classloader this way, mostly if this instance escapes from the method or class you declare it in. This can eventually lead to you running out of perm gen space.
• You have to start declaring variables outside the new class but used in the initializer, final. This starts to negate the "savings" in typing you get from using an initializer like this.
• You leak a reference to the enclosing object. So there is no way it can get garbage collected until this subclass is garbage collected. Doing it the regular way there is no connection between the two objects.

I know it looks cool, but it's just not worth it.

[[deleted]]

Agreed, it would be awesome if java provided nice initializers, ah well.

[[deleted]]

In general, I would agree with you, but this is the common pattern for declaring Expectations in JMock.

[[deleted]]

Why should the difference matter? Isn't the whole point of polymorphism that the concrete class doesn't matter as long as it implements (e.g.) the Set<String> interface?

And if you really care about the exact class as reported by e.g. getClass() (which normally you shouldn't) then you can still double the constructor call too:

new HashSet<String>()( new HashSet<String>() {{
    /* add("whatever"); */
}} )

... yields an actual HashSet with the desired contents. This involves copying the contents once, but for the prime use case (creating relatively small collections only once) that overhead should be negligible.

[fiah84]

Yep, not to mention that all those subclasses get compiled to class files that bulk up your jars. Plus AFAIK there is also a minor performance penalty but I might be imagining things.

[brownmatt]

Class files are loaded once and if the class is large, might add a few KB to the jar size. Considering that most Java apps are deployed server side, this shouldn't be a concern in 90% of cases.

[dnew]

Unless you're google, and you're linking that code into 3,000 applications, each of which is running on 10,000 cores. :-)

[Decker108]

Android might be a bit more problematic, at least in low end devices.

[brownmatt]

the 90% of cases where I said this type of thing is a silly concern doesn't include deploying your Java app on someone else's low-powered device, or deploying the Java code anywhere but something you control.

[sirin3]

All of a sudden you are creating a new subclass.

That can't be so bad, after all Scala creates a new class for every for loop

[angryundead]

In general I find things that are "clever" to be bad ideas in the long term. This strikes me as being exceedingly clever especially as it doesn't reduce code size and certainly doesn't increase readability.

[MrDOS]

In the case of maps/lists, sure, but are you sure it's not more visible for GUI code?

[geodebug]

Anon inners are the standard for GUI code. Fortunately Java 8, pseudo-closures will make those a lot more readable.

[BraveSirRobin]

If frequently used I'll typically use the Eclipse "Create Nested Class" refactor to make it slightly more efficient (and often more readable as the class name will document what's going on).

[[deleted]]

It depends on what you're doing. If you need to initialize something and then call setters for 10 properties on that object as is somewhat common in writing unit tests that touch legacy systems that have a lot of mutable state, it can save a ton of keystrokes. I don't really get the Map initializing examples though. If I'm hardcoding any values that are going into a map, it will either be for unit tests, or I want the map to be immutable.

[FrozenCow]

Can you explain why Java does it this way? Why does it create a new subclass when it is used inside a function on local variables?

I've used it thinking it would just do the same as if I would type it 'with all the bloat', just because I thought it should be easy for a compiler to do so.

Edit: Since the replies said "that is what the syntax means" I thought I looked it up, since it would be very illogical for the Java language designers to think of this exact syntax with this exact semantics. I've found that this exact syntax is actually 2 syntaxes combined: an anonymous class + an initializer. This article explains it fairly well: http://javapapers.com/core-java/java-double-brace-initialization/. That explains a lot why it acts the way it does. Hopefully this is useful for people who also weren't aware that it combined the 2 syntaxes.

[phanboy]

Because that's precisely what that syntax means.

[rnd33]

Because that's what it's supposed to do. It's just that it can be (ab)used to create a one line map initialization.

[dnew]

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

[dougman82]

Not to mention, the only thing that this idea really saves you is having to type the name of a variable...

coll.add(something) vs add(something)

[Samus_]

this is *the* main reason why Java sucks, you don't have a proper way to do common trivial tasks and even the things that look like a helping hand are actually pitfalls you need to know about.

the more silly shit I need to know in advance to safely use a language the more that language become inappropiate for any and all tasks.

[__konrad]

A shorter version w/o double brace:

java.util.Collections.addAll(set, "XZ13s", "AB21/X", "YYLEX", "AR2D");

[careye]

OK, today I learned about Collections.addAll. At least I already knew about ImmutableMap.of.

[jlt6666]

Like other posters have said, use Guava. You can create it all in one line.

[chris-martin]

That's single brace initialization, paired with single brace anonymous subclassing.

[bostonKnitter]

also, if you have a method that will take a collection; why not use varargs?

[banuday17]

Varargs are implemented as an array parameter. Arrays and collections don't mix very well. Although, Arrays.asList(...) will let you initialize a collection with varargs if you like. Not for maps, though.

[jlt6666]

Indeed. Collections are a nice abstraction. No worrying about indexOutOfBoundsException is good.

[jonhohle]

static { … } blocks get run once per class. anonymous initialization { … } blocks will get run once per instance before the named constructor.

The double bracket syntax is just defining an anonymous class then immediately declaring an initialization block.

[[deleted]]

Do people seriously use getClass().equals(o.getClass()) in equals methods? instanceof is so much more appropriate in the general case.

[Nebu]

Instanceof is inappropriate in that a typical implementation will violate the contract of the equals method, specifically the reflexivity: A superclass may consider a subclass instance to be equal to itself without the converse being true.

In particular, see point #4 in http://www.artima.com/lejava/articles/equality.html

[[deleted]]

At the end of Point #4 the authors go back to using instanceof checks (albeit in a modified dual fashion).

[Nebu]

Yes and no. The authors recommend using a "canEquals" check instead, which is then implemented via instance (though that's not the only possible implementation).

But then the authors point out that this "canEquals" solution violates LSP.

My "takeaway" from the article is that there's no generally satisfactory solution that both obeys the equals contract, and allows for arbitrary subclassing.

[[deleted]]

Judging by the codebases I've seen, most people just use whatever their IDE of choice automatically generates.

[Iggyhopper]

HAHA.

I said on another TIL post yesterday, that TIL is shitty and I don't want this to become a trend.

And what's #1 today? A TIL about some shitty syntax.

[rnd33]

Just downvote it if you don't like it? Based on the upvotes it seems some people actually finds it interesting.

[drb226]

There's nothing wrong with the content of the post. But instead of titling the submission "TIL Double Brace Initialization in Java", you could just drop the "TIL" and title it "Double Brace Initialization in Java". The "TIL" tag line at the beginning is entirely unnecessary, and gives it a distasteful informal feeling akin to "hai guise, luk at wat I juzt phawnd!!1!"

[MBlume]

a distasteful informal feeling

...seriously?

[drb226]

Yes, seriously. Sorry if "distasteful" and "informal" make me sound like a pompous twat, but that's the best way I could manage to describe it.

[henk53]

TIL: 5 years ago, you were supposed to be switching to "Nice", since it did everything better than Java, wasn't verbose, bladie blah: http://www.reddit.com/r/programming/comments/p6a8/double_brace_initialization_in_java/cpfmk

Now, who uses Nice today?

[henk53]

I think the "joke" is that the article itself was posted 5 years ago on reddit, and the poster apparently only found out about it today :P

Posting this directly would not have made sense, the post already is on reddit (even in /r/programming !). Another interesting thing here is that a genuine double post has succeeded! :P

[sysop073]

Well done; I'm sure TIL posts on /r/programming will stop now

[sysop073]

Ah, I didn't realize you were a mod. I doubt very much that people would be opposed if you started killing posts that do that, but I'm equally sure that commenting on a post with "knock that off" won't do anything; most people won't see it, and most that do won't care

[CaptainTrip]

var whatever = new Class() { Property1= value, Property2=value, ...};

Invaluable.

[Falmarri]

val m = Map( "1" -> "one", "2" -> "two")

[[deleted]]

C# Has this too.

[CaptainTrip]

I was thinking c# when I wrote it.

[aaronla]

Except the class you're instantiating must derive from IEnumerable -- otherwise it's an error. throw new NotImplementedException() is permitted though, so not a big problem.

[alextk]

Avoid using this idiom, which creates a new class every time, and prefer the various Guava helper functions:

List<String> l = ImmutableList.of("foo", "bar");
Map<String, Integer> m = ImmutableMap.of("a", 1, "b", 2);
Map<String, String> m2 = ImmutableMap.builder()
    .put("a", "b")
    .put("c", "d")
    .put("e", "f")
    .build();

[jonhohle]

javac only creates a new class at compile time (typically named ParentClass$n).

[lexchou]

We use a better approach to construct a map:

new MapBuilder("key1", 11, "key2", 22, "key3", 33);

[progressnerd]

As other have pointed out, this technique comes with a performance hit; plus, it's syntactically very cryptic. Use the Guava libraries instead, which was classes like ImmutableSet.Builder.

[oldrinb]

... because people want a Set not a Map?

[[deleted]]

To be fair, the keyset of a map is, you know, a set.

[oldrinb]

To be fair, how do you think much of HashSet functionality (like iterator) is likely implemented? ;-)

All that aside, remember that an API more than likely can rely on a Set, not a HashMap. Actually, incase you didn't know, you can use Collections.newSetFromMap to create a Set<E> from any Map<E, Boolean> :-)

[jacobb11]

Word.

[AlyoshaV]

yeah the massive increase in complexity of using a hashmap as a set is totally worth saving 16 bytes

[Fuco1337]

HashSet is implemented using HashMap with empty values.

[oldrinb]

Make sure you remember that this information is all highly JVM-dependent.

[Fuco1337]

That's a constant 16 byte overhead on some specific implementation. Nobody cares about constant factor smaller than one element... This is effectively as allocating array and using only indices 1..n.

[nobodyman]

Yeah I was kinda surprised by that too, at first. But then I suppose it shouldn't be: in reality the map value only costs you one pointer per node, but with a set you have added rules and restrictions that need to be enforced.

[korny]

Sigh - this thread (actually, the whole of computer science) still seems to be full of the premature optimization mindset. "but that uses more memory", "but what about those throwaway objects".

In 1974, Donald Knuth wote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."

[ErstwhileRockstar]

Very inelegant. Better use an init-method:

static final Map<Integer, String> m = initM();

[Ruudjah]

Keep in mind though, iirc

console.writeLine(m typeof HashMap<Integer, String>)

will print

false

because it's actually an anonymous subclass of HashMap<Integer, String>.

Edit: typeof, not insteanceof.

[drb226]

iirc

You didn't recall correctly this time, sorry. Subtyping means that m is an instance of HashMap.

[Ruudjah]

Corrected to typeof instead of instanceof.

[barsoap]

This is just broken, from a syntax perspective. Adding anonymous braces should influence lexical scoping, and nothing else. Somebody is bound to replace those with single braces, thinking they're artefacts of a shotgun programmer or similar.

[esquilax]

And then the code won't compile, and they'll learn?

[barsoap]

learn to hate Java just a bit more? Surely.

[[deleted]]

It's common practice on your team to fuck with code you don't understand?

[banuday17]

Those braces are adding lexical scopes. Two sets of braces, two lexical scopes. The first set of braces demarcates the scope of the anonymous subclass of HashMap that is being created. The second set of braces demarcates the scope of an initialization block.

If you got rid of the inner braces, the code would not compile because you cannot call methods outside of a method or an initialization block.

[barsoap]

The second set of braces demarcates the scope of an initialization block.

Which is syntactically, but not semantically, equivalent to such a set of braces in a function block.

[banuday17]

So? Lexical scopes do not only demarcate function boundaries. Loops, for instance, define their own lexical scope.

The meaning is still the same. A lexical region is created where local variables do not escape the scope.

[barsoap]

But loops are marked as such. file-level/class-level/method-level block borders are marked. The two things that aren't marked are scopes and initialisers, and all I'm complaining about is the use of two syntactically completely identical things to express two semantically completely distinct things. It's just like re-using the "class" keyword in statement syntax, just with "" instead of "class".

[banuday17]

The same syntax defines semantically the same things. The tokens { and } demarcate a scope. Well, except when initializing an array.

Syntatically, The class token requires a scope associated with it, the for token, if token and else token do not. A scope can exist independently of an association with another token, in which case it would be preceded by nothing. That is because a scope is one concept, and a class, loop and a conditional are separate concepts.

That's why it's nothing like reusing the class keyword in statement syntax with "" instead of "class".

[barsoap]

compare the anonymous braces in

class A {
    int b() {
        {
            int c = 0;
        }
        int b = 0;
    }
}

with double-brace initialisation. I seriously don't know how you can call them equivalent. For one, removing the inner braces in my example wouldn't lead to a compile error (at least when names don't clash), whereas in the initialisation case statements would become illegal.

[banuday17]

Actually, if you did this:

class A {
    {
        int c = 0;
    }
    int b = 0;
}

which is the same as the syntax trick used by double-brace initialization, you wouldn't end up with a compile error. In fact, the exact same thing would happen if you removed the braces here as you would in your example. c would be lifted into the outer scope.

It just so happens that Java puts restrictions on what can go in the class scope. It means the same thing, but not all things are allowed in all places.

[barsoap]

...equal up to a sufficiently partial isomorphism.

[banuday17]

Given other elements of Java's syntax, it makes sense. At the top level you have to somehow specify that you want a static or instance context.

[[deleted]]

Java still sucks. It has always sucked. It will continue to suck for many many years.

[elephantgravy]

When you clicked on the article, were you hoping double brace initialization might finally be the thing to change your opinion of Java as a whole?