En Hidden Features of Java, la respuesta principal menciona Double Brace Initialization , con una sintaxis muy atractiva:

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

Este idioma crea una clase interna anónima con solo un inicializador de instancia, que "puede usar cualquier método [...] en el ámbito de contención".

Pregunta principal: ¿Es tan ineficiente como parece? ¿Debería limitarse su uso a inicializaciones únicas? (¡Y por supuesto presumiendo!)

Segunda pregunta: El nuevo HashSet debe ser el "this" utilizado en el inicializador de instancia ... ¿alguien puede arrojar luz sobre el mecanismo?

Tercera pregunta: ¿Es este idioma demasiado oscuro para usar en el código de producción?

Resumen: Muy, muy buenas respuestas, gracias a todos. En la pregunta (3), la gente sintió que la sintaxis debería ser clara (aunque recomendaría un comentario ocasional, especialmente si su código pasará a los desarrolladores que pueden no estar familiarizados con él).

En la pregunta (1), el código generado debería ejecutarse rápidamente. Los archivos .class adicionales causan desorden en los archivos jar y retrasan un poco el inicio del programa (gracias a @coobird por medir eso). @Thilo señaló que la recolección de basura puede verse afectada, y el costo de memoria para las clases cargadas adicionales puede ser un factor en algunos casos.

La pregunta (2) resultó ser la más interesante para mí. Si entiendo las respuestas, lo que sucede en DBI es que la clase interna anónima extiende la clase del objeto que está construyendo el nuevo operador y, por lo tanto, tiene un "este" valor que hace referencia a la instancia que se está construyendo. Muy aseado.

En general, DBI me parece una especie de curiosidad intelectual. Coobird y otros señalan que puede lograr el mismo efecto con Arrays.asList, métodos varargs, Google Collections y los literales propuestos para la Colección Java 7. Los nuevos lenguajes JVM como Scala, JRuby y Groovy también ofrecen anotaciones concisas para la construcción de listas, e interoperan bien con Java. Dado que DBI abarrota el classpath, ralentiza un poco la carga de la clase y hace que el código sea un poco más oscuro, probablemente lo evitaría. ¡Sin embargo, planeo lanzar esto a un amigo que acaba de obtener su SCJP y ama las justas bondadosas sobre la semántica de Java! ;-) ¡Gracias a todos!

7/2017: Baeldung tiene un buen resumen de la inicialización de doble paréntesis y lo considera un antipatrón.

12/2017: @Basil Bourque señala que en el nuevo Java 9 puedes decir:

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

Ese es seguro el camino a seguir. Si está atascado con una versión anterior, eche un vistazo a ImmutableSet de Google Collections .

Aquí está el problema cuando me dejo llevar por las clases internas anónimas:

2009/05/27  16:35             1,602 DemoApp2$1.class
2009/05/27  16:35             1,976 DemoApp2$10.class
2009/05/27  16:35             1,919 DemoApp2$11.class
2009/05/27  16:35             2,404 DemoApp2$12.class
2009/05/27  16:35             1,197 DemoApp2$13.class

/* snip */

2009/05/27  16:35             1,953 DemoApp2$30.class
2009/05/27  16:35             1,910 DemoApp2$31.class
2009/05/27  16:35             2,007 DemoApp2$32.class
2009/05/27  16:35               926 DemoApp2$33$1$1.class
2009/05/27  16:35             4,104 DemoApp2$33$1.class
2009/05/27  16:35             2,849 DemoApp2$33.class
2009/05/27  16:35               926 DemoApp2$34$1$1.class
2009/05/27  16:35             4,234 DemoApp2$34$1.class
2009/05/27  16:35             2,849 DemoApp2$34.class

/* snip */

2009/05/27  16:35               614 DemoApp2$40.class
2009/05/27  16:35             2,344 DemoApp2$5.class
2009/05/27  16:35             1,551 DemoApp2$6.class
2009/05/27  16:35             1,604 DemoApp2$7.class
2009/05/27  16:35             1,809 DemoApp2$8.class
2009/05/27  16:35             2,022 DemoApp2$9.class

Estas son todas las clases que se generaron cuando estaba haciendo una aplicación simple, y utilicé grandes cantidades de clases internas anónimas: cada clase se compilará en un classarchivo separado .

La "inicialización de doble paréntesis", como ya se mencionó, es una clase interna anónima con un bloque de inicialización de instancia, lo que significa que se crea una nueva clase para cada "inicialización", todo con el propósito de hacer generalmente un solo objeto.

Teniendo en cuenta que Java Virtual Machine necesitará leer todas esas clases cuando las use, eso puede llevar algún tiempo en el proceso de verificación de bytecode y tal. Sin mencionar el aumento en el espacio en disco necesario para almacenar todos esosclass archivos.

Parece que hay un poco de sobrecarga cuando se utiliza la inicialización de doble paréntesis, por lo que probablemente no sea una buena idea ir demasiado por la borda. Pero como ha señalado Eddie en los comentarios, no es posible estar absolutamente seguro del impacto.

Solo como referencia, la inicialización de doble llave es la siguiente:

List<String> list = new ArrayList<String>() {{
    add("Hello");
    add("World!");
}};

Parece una característica "oculta" de Java, pero es solo una reescritura de:

List<String> list = new ArrayList<String>() {

    // Instance initialization block
    {
        add("Hello");
        add("World!");
    }
};

Entonces, es básicamente un bloque de inicialización de instancia que es parte de una clase interna anónima .

La propuesta de Joshua Bloch's Collection Literals para Project Coin fue similar a :

List<Integer> intList = [1, 2, 3, 4];

Set<String> strSet = {"Apple", "Banana", "Cactus"};

Map<String, Integer> truthMap = { "answer" : 42 };

Lamentablemente, no llegó a Java 7 ni 8 y se archivó indefinidamente.

Experimentar

Aquí está el experimento simple que probé: crea 1000 ArrayLists con los elementos "Hello"y los "World!"agrega a través del addmétodo, usando los dos métodos:

Método 1: inicialización de doble llave

List<String> l = new ArrayList<String>() {{
  add("Hello");
  add("World!");
}};

Método 2: crear una instancia de ArrayListyadd

List<String> l = new ArrayList<String>();
l.add("Hello");
l.add("World!");

Creé un programa simple para escribir un archivo fuente Java para realizar 1000 inicializaciones usando los dos métodos:

Prueba 1:

class Test1 {
  public static void main(String[] s) {
    long st = System.currentTimeMillis();

    List<String> l0 = new ArrayList<String>() {{
      add("Hello");
      add("World!");
    }};

    List<String> l1 = new ArrayList<String>() {{
      add("Hello");
      add("World!");
    }};

    /* snip */

    List<String> l999 = new ArrayList<String>() {{
      add("Hello");
      add("World!");
    }};

    System.out.println(System.currentTimeMillis() - st);
  }
}

Prueba 2:

class Test2 {
  public static void main(String[] s) {
    long st = System.currentTimeMillis();

    List<String> l0 = new ArrayList<String>();
    l0.add("Hello");
    l0.add("World!");

    List<String> l1 = new ArrayList<String>();
    l1.add("Hello");
    l1.add("World!");

    /* snip */

    List<String> l999 = new ArrayList<String>();
    l999.add("Hello");
    l999.add("World!");

    System.out.println(System.currentTimeMillis() - st);
  }
}

Tenga en cuenta que el tiempo transcurrido para inicializar la ArrayListextensión de 1000 sy 1000 clases anónimas internas ArrayListse verifica utilizando elSystem.currentTimeMillis , por lo que el temporizador no tiene una resolución muy alta. En mi sistema Windows, la resolución es de alrededor de 15-16 milisegundos.

Los resultados para 10 ejecuciones de las dos pruebas fueron los siguientes:

Test1 Times (ms)           Test2 Times (ms)
----------------           ----------------
           187                          0
           203                          0
           203                          0
           188                          0
           188                          0
           187                          0
           203                          0
           188                          0
           188                          0
           203                          0

Como se puede ver, la inicialización de doble llave tiene un tiempo de ejecución notable de alrededor de 190 ms.

Mientras tanto, el ArrayListtiempo de ejecución de la inicialización resultó ser de 0 ms. Por supuesto, la resolución del temporizador debe tenerse en cuenta, pero es probable que sea inferior a 15 ms.

Entonces, parece haber una diferencia notable en el tiempo de ejecución de los dos métodos. Parece que de hecho hay algo de sobrecarga en los dos métodos de inicialización.

Y sí, se .classgeneraron 1000 archivos al compilar el Test1programa de prueba de inicialización de doble paréntesis.

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

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

Segunda pregunta: El nuevo HashSet debe ser el "this" utilizado en el inicializador de instancia ... ¿alguien puede arrojar luz sobre el mecanismo? Ingenuamente esperaba que "esto" se refiriera al objeto que inicializa "sabores".

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

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 puede definir métodos allí. Por ejemplo, anularHashSet.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 llave, un gatito es asesinado.

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

1. Estás creando demasiadas clases anónimas

Cada vez que utiliza la inicialización de doble llave se crea una nueva clase. Por ejemplo, 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 bastante sobrecarga para tu cargador de clases, ¡para nada! Por supuesto, no tomará mucho tiempo de inicialización si lo hace una vez. Pero si hace esto 20,000 veces en toda su aplicación empresarial ... ¿toda esa memoria de almacenamiento dinámico solo por un poco de "sintaxis de azúcar"?

2. ¡Potencialmente estás creando una pérdida de memoria!

Si toma el código anterior y devuelve ese mapa de un método, las personas que llaman de ese método podrían estar aferrándose a recursos muy pesados ​​que no se pueden recolectar 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 devuelto Mapcontendrá ahora una referencia a la instancia adjunta de ReallyHeavyObject. Probablemente no quiera arriesgarse 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

Para responder a su pregunta real, la gente ha estado usando esta sintaxis para pretender que Java tiene algo así como literales de mapas, 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 descompilando 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 me preocupara el rendimiento de algo como esto, lo perfilaría. Y su pregunta # 2 es respondida por el código anterior: está dentro de un constructor implícito (e inicializador de instancia) para su clase interna, por lo que " this" se refiere a esta clase interna.

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

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 el 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, el compilador convierte el bloque de código entre {y }. Con esto en mente, desentraña 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 más internas se convierte en un constructor por el compilador. Las llaves más externas delimitan la clase interna anónima. Para dar este paso final, hacer que todo sea 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 fines de inicialización, diría que no hay gastos generales (o tan pequeños que se pueden descuidar). Sin embargo, cada uso de flavorsno irá en contraHashSet sino en contra MyHashSet. Probablemente hay una pequeña sobrecarga (y posiblemente insignificante) para esto. Pero de nuevo, antes de preocuparme por eso, lo perfilaría.

Nuevamente, a su pregunta # 2, el código anterior es el equivalente lógico y explícito de la inicialización de doble paréntesis, y hace obvio dónde " this" se refiere: a la clase interna que se extiendeHashSet .

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

propenso a fugas

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

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

Entonces, si el conjunto se escapa a cualquier otra parte cargada por un cargador de clases diferente y se mantiene una referencia allí, se filtrará todo el árbol de clases + cargador de clases. Para evitar que, una copia a HashMap es necesario, new LinkedHashSet(new ArrayList(){{add("xxx);add("yyy");}}). Ya no es tan lindo. Yo no uso el idioma, 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();
    }
}

huellas dactilares

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 de 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 Google Collections tiene muchos métodos convenientes como este, así como muchas otras funcionalidades útiles.

En cuanto a la oscuridad del idioma, lo encuentro y lo uso en el código de producción todo el tiempo. Estaría más preocupado por los programadores que se confunden con el idioma que se les permite escribir código de producción.

Dejando de lado la eficiencia, rara vez me encuentro deseando crear una colección declarativa fuera de las pruebas unitarias. Creo que la sintaxis de doble paréntesis 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 puede controlar el tipo específico de lista que se generará.

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

Vería el problema más desde el punto de vista de si desea "desordenar las cosas" con muchas clases anónimas. Como una guía aproximada, considere usar el idioma 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, por lo 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 mantenga su código, supongo. Si no sabe esto de antemano, entonces un punto de referencia que sugeriría usar es "¿ve 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 único contenido de la clase anónima). En la mayoría de los proyectos de tamaño moderado, diría que realmente necesitará que sus programadores comprendan la fuente JDK en algún momento u otro, por lo que cualquier sintaxis o modismo utilizado allí es un "juego justo". Más allá de eso, diría, capacite a las personas en esa sintaxis si tiene control sobre quién mantiene el código, de lo contrario, comente o evite.

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

No hay una razón legítima para usar este "truco". Guava proporciona colecciones agradables e inmutables que incluyen tanto fábricas estáticas como constructores, lo que le permite poblar 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");

Esto 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 construido directamente HashMap, pero es peligroso y propenso a errores, y hay mejores opciones.

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

Propenso a errores ahora marca este antipatrón .

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ó descubrir que en la mayoría de las pruebas de ejecución la iniciación interna fue realmente más rápida (casi el doble en algunos casos). Cuando se trabaja con grandes cantidades, el beneficio parece desvanecerse.

Curiosamente, el caso que crea 3 objetos en el bucle pierde su beneficio se reduce antes que en los otros casos. No estoy seguro de por qué sucede esto y se deben realizar más pruebas para llegar a conclusiones. Crear implementaciones concretas puede ayudar a evitar que la definición de 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 iniciaciones de doble llave crea un nuevo archivo de clase que agrega un bloque de disco completo al tamaño de nuestra aplicación (o aproximadamente 1k cuando está comprimido). Una huella pequeña, pero si se usa en muchos lugares, podría tener un impacto potencial. Use esto 1000 veces y posiblemente esté agregando un MiB completo a su aplicación, lo que puede ser preocupante en un entorno integrado.

¿Mi conclusión? Puede estar bien usarlo siempre que no se abuse de él.

Déjame saber lo que piensas :)

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

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 de $ 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 creadores banales, especialmente para las constantes, y los lugares donde las subclases anónimas no importan (como no hay serialización involucrada).

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

É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, respalda 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 todas las clases de Java que escribo, son métodos estáticos que reducen la cantidad de pulsaciones de teclas repetitivas en su código Java. Es muy conveniente poder ingresar comandos como los siguientes:

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

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

10/07/2014: Si tan solo pudiera ser tan simple como el de Python:

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

21/02/2020: en Java 11 ahora puedes decir:

animals = List.of(“cat”, “dog”, “horse”)

1. Esto llamará add()a cada miembro. Si puede encontrar una forma más eficiente de colocar elementos en un conjunto hash, entonces úselo. Tenga en cuenta que la clase interna probablemente generará basura, si es sensible al respecto.

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

3. Si necesita preguntar ... Más probablemente: ¿las personas que vienen después de usted lo saben o no? ¿Es fácil de entender y explicar? Si puede responder "sí" a ambas, siéntase libre de usarlo.