Atajo para la creación de una Lista typesfe o Set en Java

Dado un método:

  weekPlanner (Lista  dowl)  

He estado escribiendo el código siguiente para pasar una lista typesafe a ella:

  List  favDays = new ArrayList <> (); 
 favDays.add (DayOfWeek.FRIDAY); 
 favDays.add (DayOfWeek.SATURDAY); 
 favDays.add (DayOfWeek.SUNDAY) ; 
 weekPlanner (favDays);  

Hoy finalmente me di cuenta de que puedo hacer esto:

  weekPlanner (Arrays.asList (DayOfWeek.FRIDAY, 
 DayOfWeek. Sábado, 
 DayOfWeek.SUNDAY));  

Incluso dice así en el JavaDoc para Arrays.asList (), pero ¿quién sabe? También puede incluir la nueva lista de Collections.unmodifiableList ()! Yo estaba muy emocionado acerca del uso de esto para hacer una clase ImmutableList para que yo pudiera hacer una llamada como la siguiente:

  weekPlanner (ImList.of (DayOfWeek.FRIDAY, 
 DayOfWeek.SATURDAY, 
 DayOfWeek.SUNDAY));  

Pero luego me di cuenta de que lo primero que me gustaría hacer es declarar mi weekPlanner para que la persona que llama sabría que el método no modificar la lista o si tiene efectos secundarios. Si weekPlanner () sólo utiliza acceso secuencial a la lista, podría declararlo como un Iterable:

  weekPlanner (Iterable  favDays)  

Probablemente aunque realmente debería usar un Set inmutable:

  weekPlanner (Imset  favDays)  

Pero ahora no puedo pasar un Conjunto mutable a más porque la interfaz java.util.Set haría que extender un conjunto inmutable para hacer eso posible. Esto explica por qué la mayoría colecciones Scala no se extienden a la API de Java Collections. Otra razón es que el método List.add () en Java (y otros métodos similares) devuelve un valor booleano lugar de una lista nueva o modificada. Tener que evitar estos métodos Java falsos en Scala sería propenso a errores. Pero eso no explica por qué la API de Java no virar en métodos como ImmutableList append (E. .. args) . Supongo que la remove () sería difícil adaptar, pero me gustaría tener una gran cantidad de kilometraje de sólo el método append …

He amado Java para años y estoy tremendamente agradecido por todo el esfuerzo que fuimos a hacer un gran lenguaje tal y lo que es, básicamente, de libre disposición. Pero las personas más inteligentes de lo que debía de haber encontrado los esqueletos mutables en el armario de Java hace años. ¿Por qué sus voces no son escuchadas por Sun y Oracle después? ¿Cuál es el lado negativo de la adición de un par de interfaces de padres immutabile a las interfaces de las colecciones de Java API (Collection, List, Mapa, Set, etc)?

Me gustaría pensar que Martin Odersky tendría abogado por la inmutabilidad antes de irse Sol y se centró en cambio en la fabricación de Scala. Pero Scala fue concebido en 2001 y lanzado en 2003. No sé si la inmutabilidad era una característica clave desde el principio, pero eso es mucho tiempo para Java para ignorarlo. Tal vez alguien que sabe más de esto me ilumine con un comentario …

Por lo menos para mí, el supuesto defecto de la mutabilidad pública de objetos en Java es mi principal motivación para mudarse a un idioma como el Scala. Los lenguajes de la JVM nuevos tienen otras grandes ventajas, pero eso es probablemente la que me hará entrar en acción.