Una propiedad de este enfoque que no se ha señalado hasta ahora es que debido a que se crean clases internas, toda la clase contenedora se captura en su ámbito. Esto significa que mientras su Conjunto esté vivo, retendrá un puntero a la instancia contenedora (this$0) y evitará que se recolecte basura, lo que podría ser un problema.

Esto, y el hecho de que una nueva clase se crea en primer lugar a pesar de que un HashSet regular funcionaría bien (o incluso mejor), hace que yo no quiero usar esta construcción (a pesar de que realmente anhelo el azúcar sintáctico).

Segunda pregunta: El nuevo HashSet debe ser el "this" usado en el inicializador de instancias ... ¿puede alguien arrojar luz sobre el mecanismo? Ingenuamente habría esperado que " esto "se refiriera al objeto inicializando"sabores".

Así es como funcionan las clases internas. Obtienen su propio this, pero también tienen punteros a la instancia padre, por lo que puede llamar a los métodos en el contenido objeta también. En caso de un conflicto de nombres, la clase interna (en su caso HashSet) tiene prioridad, pero puede prefijar "esto" con un nombre de clase para obtener el método externo también.

public class Test {

    public void add(Object o) {
    }

    public Set<String> makeSet() {
        return new HashSet<String>() {
            {
              add("hello"); // HashSet
              Test.this.add("hello"); // outer instance 
            }
        };
    }
}

Para ser claro sobre la subclase anónima que se está creando, también podría definir métodos allí. Por ejemplo, override HashSet.add()

    public Set<String> makeSet() {
        return new HashSet<String>() {
            {
              add("hello"); // not HashSet anymore ...
            }

            @Override
            boolean add(String s){

            }

        };
    }

Cada vez que alguien usa la inicialización de doble corsé, un gatito muere.

Aparte de que la sintaxis es bastante inusual y no realmente idiomática (el sabor es discutible, por supuesto), está creando innecesariamente dos problemas significativos en su aplicación, que acabo de bloguear recientemente con más detalle aquí.

1. Estás creando demasiadas clases anónimas

Cada vez que se usa la inicialización de doble llave, se crea una nueva clase. E. g. este ejemplo:

Map source = new HashMap(){{
    put("firstName", "John");
    put("lastName", "Smith");
    put("organizations", new HashMap(){{
        put("0", new HashMap(){{
            put("id", "1234");
        }});
        put("abc", new HashMap(){{
            put("id", "5678");
        }});
    }});
}};

... producirá estas clases:

Test$1$1$1.class
Test$1$1$2.class
Test$1$1.class
Test$1.class
Test.class

Eso es un poco de sobrecarga para su classloader - para nada! Por supuesto, no tomará mucho tiempo de inicialización si lo haces una vez. Pero si lo hace 20 ' 000 veces a través de su aplicación empresarial... todo ese montón de memoria sólo por un poco de "azúcar de sintaxis"?

2. ¡Estás potencialmente creando una fuga de memoria!

Si toma el código anterior y devuelve ese mapa de un método, los llamantes de ese método podría ser sin sospechar aferrarse a recursos muy pesados que no se pueden recoger basura. Considere el siguiente ejemplo:

public class ReallyHeavyObject {

    // Just to illustrate...
    private int[] tonsOfValues;
    private Resource[] tonsOfResources;

    // This method almost does nothing
    public Map quickHarmlessMethod() {
        Map source = new HashMap(){{
            put("firstName", "John");
            put("lastName", "Smith");
            put("organizations", new HashMap(){{
                put("0", new HashMap(){{
                    put("id", "1234");
                }});
                put("abc", new HashMap(){{
                    put("id", "5678");
                }});
            }});
        }};

        return source;
    }
}

El Map devuelto ahora contendrá una referencia a la instancia adjunta de ReallyHeavyObject. Probablemente no quieras arriesgarte a que:

_{Imagen de http://blog.jooq.org/2014/12/08/dont-be-clever-the-double-curly-braces-anti-pattern/}

3. Puede pretender que Java tiene literales de mapa

A responda a su pregunta real, la gente ha estado usando esta sintaxis para pretender que Java tiene algo como literales de mapa, similar a los literales de matriz existentes:

String[] array = { "John", "Doe" };
Map map = new HashMap() {{ put("John", "Doe"); }};

Algunas personas pueden encontrar esto sintácticamente estimulante.

Tomando la siguiente clase de prueba:

public class Test {
  public void test() {
    Set<String> flavors = new HashSet<String>() {{
        add("vanilla");
        add("strawberry");
        add("chocolate");
        add("butter pecan");
    }};
  }
}

Y luego descompilar el archivo de clase, veo:

public class Test {
  public void test() {
    java.util.Set flavors = new HashSet() {

      final Test this$0;

      {
        this$0 = Test.this;
        super();
        add("vanilla");
        add("strawberry");
        add("chocolate");
        add("butter pecan");
      }
    };
  }
}

Esto no me parece terriblemente ineficiente. Si estuviera preocupado por el rendimiento para algo como esto, lo haría perfil. Y tu pregunta #2 es respondida por el código anterior: Estás dentro de un constructor implícito (e inicializador de instancia) para tu clase interna, así que "this" se refiere a esta clase interna.

Sí, esta sintaxis es oscura, pero un comentario puede aclarar uso de sintaxis oscura. Para aclarar la sintaxis, la mayoría de las personas están familiarizadas con un bloque inicializador estático (Inicializadores estáticos JLS 8.7):

public class Sample1 {
    private static final String someVar;
    static {
        String temp = null;
        ..... // block of code setting temp
        someVar = temp;
    }
}

También puede usar una sintaxis similar (sin la palabra "static") para el uso del constructor (Inicializadores de instancia JLS 8.6), aunque nunca he visto esto usado en código de producción. Esto es mucho menos conocido.

public class Sample2 {
    private final String someVar;

    // This is an instance initializer
    {
        String temp = null;
        ..... // block of code setting temp
        someVar = temp;
    }
}

Si no tiene un constructor predeterminado, entonces el bloque de código entre { y } se convierte en un constructor por el compilador. Con esto en mente, desentrañar el código de doble llave:

public void test() {
  Set<String> flavors = new HashSet<String>() {
      {
        add("vanilla");
        add("strawberry");
        add("chocolate");
        add("butter pecan");
      }
  };
}

El bloque de código entre las llaves internas se convierte en un constructor por el compilador. Las llaves más externas delimitan la clase interna anónima. Para tomar esto el paso final de hacer todo no anónimo:

public void test() {
  Set<String> flavors = new MyHashSet();
}

class MyHashSet extends HashSet<String>() {
    public MyHashSet() {
        add("vanilla");
        add("strawberry");
        add("chocolate");
        add("butter pecan");
    }
}

Para propósitos de inicialización, yo diría que no hay sobrecarga alguna (o tan pequeña que pueda ser descuidada). Sin embargo, cada uso de flavors no irá en contra de HashSet sino en lugar de MyHashSet. Probablemente hay una pequeña (y muy posiblemente insignificante) sobrecarga a esto. Pero de nuevo, antes de preocuparme por ello, lo perfilaría.

Nuevamente, para tu pregunta #2, el código anterior es el equivalente lógico y explícito de la inicialización de doble llave, y hace obvio dónde "this" se refiere: A la clase interna que se extiende HashSet.

Si tiene preguntas sobre los detalles de los inicializadores de instancia, consulte los detalles en el JLS documentación.

Propenso a fugas

He decidido intervenir. El impacto en el rendimiento incluye: operación del disco + descompresión (para jar), verificación de clase, espacio perm-gen (para Sun's Hotspot JVM). Sin embargo, lo peor de todo: es propenso a fugas. No puedes simplemente regresar.

Set<String> getFlavors(){
  return Collections.unmodifiableSet(flavors)
}

Así que si el conjunto escapa a cualquier otra parte cargada por un classloader diferente y se mantiene una referencia allí, se filtrará todo el árbol de clases+classloader. Para evitar esto, es necesaria una copia a HashMap, new LinkedHashSet(new ArrayList(){{add("xxx);add("yyy");}}). No es así ya es lindo. Yo no uso el modismo, en cambio es como new LinkedHashSet(Arrays.asList("xxx","YYY"));

Cargar muchas clases puede agregar algunos milisegundos al inicio. Si el inicio no es tan crítico y se observa la eficiencia de las clases después del inicio, no hay diferencia.

package vanilla.java.perfeg.doublebracket;

import java.util.*;

/**
 * @author plawrey
 */
public class DoubleBracketMain {
    public static void main(String... args) {
        final List<String> list1 = new ArrayList<String>() {
            {
                add("Hello");
                add("World");
                add("!!!");
            }
        };
        List<String> list2 = new ArrayList<String>(list1);
        Set<String> set1 = new LinkedHashSet<String>() {
            {
                addAll(list1);
            }
        };
        Set<String> set2 = new LinkedHashSet<String>();
        set2.addAll(list1);
        Map<Integer, String> map1 = new LinkedHashMap<Integer, String>() {
            {
                put(1, "one");
                put(2, "two");
                put(3, "three");
            }
        };
        Map<Integer, String> map2 = new LinkedHashMap<Integer, String>();
        map2.putAll(map1);

        for (int i = 0; i < 10; i++) {
            long dbTimes = timeComparison(list1, list1)
                    + timeComparison(set1, set1)
                    + timeComparison(map1.keySet(), map1.keySet())
                    + timeComparison(map1.values(), map1.values());
            long times = timeComparison(list2, list2)
                    + timeComparison(set2, set2)
                    + timeComparison(map2.keySet(), map2.keySet())
                    + timeComparison(map2.values(), map2.values());
            if (i > 0)
                System.out.printf("double braced collections took %,d ns and plain collections took %,d ns%n", dbTimes, times);
        }
    }

    public static long timeComparison(Collection a, Collection b) {
        long start = System.nanoTime();
        int runs = 10000000;
        for (int i = 0; i < runs; i++)
            compareCollections(a, b);
        long rate = (System.nanoTime() - start) / runs;
        return rate;
    }

    public static void compareCollections(Collection a, Collection b) {
        if (!a.equals(b) && a.hashCode() != b.hashCode() && !a.toString().equals(b.toString()))
            throw new AssertionError();
    }
}

Imprime

double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 34 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns
double braced collections took 36 ns and plain collections took 36 ns

Para crear conjuntos puede usar un método de fábrica varargs en lugar de la inicialización de doble llave:

public static Set<T> setOf(T ... elements) {
    return new HashSet<T>(Arrays.asList(elements));
}

La biblioteca de colecciones de Google tiene un montón de métodos de conveniencia como este, así como un montón de otras funciones útiles.

En cuanto a la oscuridad del modismo, lo encuentro y lo uso en código de producción todo el tiempo. Me preocuparía más que los programadores que se confundan por el idioma se les permita escribir código de producción.

Eficiencia aparte, rara vez me encuentro deseando para la creación de colección declarativa fuera de las pruebas unitarias. Creo que la sintaxis de doble llave es muy legible.

Otra forma de lograr la construcción declarativa de listas específicamente es usar Arrays.asList(T ...) así:

List<String> aList = Arrays.asList("vanilla", "strawberry", "chocolate");

La limitación de este enfoque es, por supuesto, que no se puede controlar el tipo específico de lista que se generará.

Generalmente no hay nada particularmente ineficiente en ello. Generalmente no le importa a la JVM que hayas creado una subclase y agregado un constructor-- eso es algo normal y cotidiano en un lenguaje orientado a objetos. Puedo pensar en casos bastante artificiales en los que podrías causar una ineficiencia al hacer esto (por ejemplo, tienes un método llamado repetidamente que termina tomando una mezcla de diferentes clases debido a esta subclase, mientras que la clase ordinaria pasada sería totalmente predecible) en el último caso, el compilador JIT podría hacer optimizaciones que no son factibles en el primero). Pero en realidad, creo que los casos en los que importará son muy ingeniosos.

Veo el problema más desde el punto de vista de si quieres "desordenar las cosas" con muchas clases anónimas. Como una guía aproximada, considere usar el modismo no más de lo que usaría, por ejemplo, clases anónimas para controladores de eventos.

En (2), estás dentro del constructor de un objeto, así que " esto" se refiere al objeto que estás construyendo. Eso no es diferente a cualquier otro constructor.

En cuanto a (3), eso realmente depende de quién está manteniendo su código, supongo. Si no sabes esto de antemano, entonces un punto de referencia que sugeriría usar es " ¿ves esto en el código fuente del JDK?"(en este caso, no recuerdo haber visto muchos inicializadores anónimos, y ciertamente no en los casos en que ese es el solo contenido de la clase anónima). En la mayoría de los proyectos de tamaño moderado, Yo diría que realmente vas a necesitar a tus programadores para entender la fuente JDK en algún momento u otro, por lo que cualquier sintaxis o lenguaje utilizado allí es "juego limpio". Más allá de eso, yo diría, entrena a la gente en esa sintaxis si tienes control de quién está manteniendo el código, si no comenta o evita.

Estaba investigando esto y decidí hacer una prueba más profunda que la proporcionada por la respuesta válida.

Aquí está el código: https://gist.github.com/4368924

Y esta es mi conclusión

Me sorprendió encontrar que en la mayoría de las pruebas de ejecución la iniciación interna era en realidad más rápida (casi el doble en algunos casos). Cuando se trabaja con grandes números, el beneficio parece desvanecerse.

Curiosamente, el caso que crea 3 objetos en el bucle pierde sus beneficios antes que en los otros casos. No estoy seguro de por qué está sucediendo esto y se deben hacer más pruebas para llegar a conclusiones. Crear implementaciones concretas puede ayudar a evitar que la definición de la clase se vuelva a cargar (si eso es lo que está sucediendo)

Sin embargo, está claro que no se observó mucha sobrecarga en la mayoría de los casos para la construcción de un solo elemento, incluso con grandes números.

Un retroceso sería el hecho de que cada una de las llaves dobles iniciaciones crea un nuevo archivo de clase que agrega un bloque de disco completo al tamaño de nuestra aplicación (o aproximadamente 1k cuando se comprime). Una huella pequeña, pero si se usa en muchos lugares podría tener un impacto potencial. Use esto 1000 veces y potencialmente está agregando un MiB completo a su aplicación, lo que puede ser preocupante en un entorno incrustado.

Mi conclusión? Puede estar bien para usar, siempre y cuando no se abusa.

Hazme saber lo que piensas:)

Secundo la respuesta de Nat, excepto que usaría un bucle en lugar de crear e inmediatamente lanzar la Lista implícita desde asList (elements):

static public Set<T> setOf(T ... elements) {
    Set set=new HashSet<T>(elements.size());
    for(T elm: elements) { set.add(elm); }
    return set;
    }

Si bien esta sintaxis puede ser conveniente, también agrega muchas de estas referencias$0 a medida que se anidan y puede ser difícil depurar en los inicializadores a menos que se establezcan puntos de interrupción en cada uno. Por esa razón, solo recomiendo usar esto para los configuradores banales, especialmente los establecidos en constantes, y los lugares donde las subclases anónimas no importan (como la no serialización involucrada).

Mario Gleichman describe cómo usar funciones genéricas de Java 1.5 para simular literales de Listas de Scala, aunque lamentablemente terminas con Listas inmutables .

Él define esta clase:

package literal;

public class collection {
    public static <T> List<T> List(T...elems){
        return Arrays.asList( elems );
    }
}

Y lo usa así:

import static literal.collection.List;
import static system.io.*;

public class CollectionDemo {
    public void demoList(){
        List<String> slist = List( "a", "b", "c" );
        List<Integer> iList = List( 1, 2, 3 );
        for( String elem : List( "a", "java", "list" ) )
            System.out.println( elem );
    }
}

Google Collections, ahora parte de Guava apoya una idea similar para la construcción de listas. En esta entrevista, Jared Levy dice:

[...] las características más utilizadas, que aparecen en casi todos los Java class I write, son métodos estáticos que reducen el número de pulsaciones de teclas repetitivas en su código Java. Es muy conveniente poder introducir comandos como los siguientes:

Map<OneClassWithALongName, AnotherClassWithALongName> = Maps.newHashMap();

List<String> animals = Lists.immutableList("cat", "dog", "horse");

7/10/2014: Si solo pudiera ser tan simple como Python:

animals = ['cat', 'dog', 'horse']

La inicialización de doble llave es un truco innecesario que puede introducir fugas de memoria y otros problemas

No hay razón legítima para usar este "truco". Guava proporciona buenas colecciones inmutables que incluyen tanto fábricas estáticas como constructores, lo que le permite rellenar su colección donde se declara en una sintaxis limpia, legible y segura .

El ejemplo en la pregunta se convierte en:

Set<String> flavors = ImmutableSet.of(
    "vanilla", "strawberry", "chocolate", "butter pecan");

No solo es más corto y fácil de leer, sino que evita los numerosos problemas con el patrón de doble refuerzo descrito en otras respuestas . Claro, funciona de manera similar a un HashMap directamente construido, pero es peligroso y propenso a errores, y hay mejores opciones.

Cada vez que se encuentre considerando la inicialización con doble refuerzo, debe volver a examinar sus API o introducir otras nuevas para abordar adecuadamente el problema, en lugar de aprovechar los trucos sintácticos.

ahora banderas propensas a errores este anti-patrón .

1. Esto llamará add() para cada miembro. Si puedes encontrar una manera más eficiente de poner elementos en un conjunto de hash, entonces usa eso. Ten en cuenta que la clase interna probablemente generará basura, si eres sensible al respecto.

2. Me parece que el contexto es el objeto devuelto por new, que es el HashSet.

3. Si necesitas preguntar... Más probable: ¿ la gente que viene después de ti lo sabrá o no? ¿Es fácil de entender y explicar? Si puedes responder "sí" a ambos, siéntase libre de usarlo.