Para la versión 7 del jdk se han aceptado siete de 10 cambios para mejorar la legibilidad y simplificar en algún aspecto el lenguaje, es por si veis que en un futuro vuestro proyecto dice que tenéis algo mal que sepáis por qué puede ser:
Los siete cambios aceptados: Strings in switch statements: esto es fácil, en los switch ahora se aceptarán cadenas de texto, un pequeño ejemplo:
Con JDK7.0:
switch(s) {
case "foo":
processFoo(s);
break;
}
java.io.InputStream, OutputStream, Reader, Writer, Formatter; java.nio.Channel;java.net.socket; java.sql.Connection, Statement, ResultSet o java.awt.Graphics.
Como el tener que cerrar algo manualmente suele ser un nido de errores (a todo el mundo se le puede olvidar, tenemos que para lo que hasta ahora es:
Caso actual:
static String readFirstLineFromFile(String path) throws IOException {
BufferedReader br = new BufferedReader(new FileReader(path));
try {
return br.readLine();
} finally {
br.close();
}
}
Con JDK7.0:
static String readFirstLineFromFile2(String path) throws IOException {
try (BufferedReader br = new BufferedReader(new FileReader(path)) {
return br.readLine();
}
}
o un ejemplo más elaborado:
Caso actual:
static void copy(String src, String dest) throws IOException {
InputStream in = new FileInputStream(src);
try {
OutputStream out = new FileOutputStream(dest);
try {
byte[] buf = new byte[8 * 1024];
int n;
while ((n = in.read(buf)) >= 0)
out.write(buf, 0, n);
} finally {
out.close();
}
} finally {
in.close();
}
}
Con JDK7.0:
static void copy(String src, String dest) throws IOException {
try (InputStream in = new FileInputStream(src);
OutputStream out = new FileOutputStream(dest)) {
byte[] buf = new byte[8192];
int n;
while ((n = in.read(buf)) >= 0)
out.write(buf, 0, n);
}
}
Esto símplemente quita una redundancia a la hora de crear algún tipo genérico, ahora ahora siempre que se crea un, por ejemplo, Map se pone el tipo de variable que es el key y el contenido en la declaración y en el new, ahora será solo en la declaración:
Hasta ahora:
Map<String, List<String>> anagrams = new HashMap<String, List<String>>();
Con JDK7.0
Map<String, List<String>> anagrams = new HashMap<>();
Simplified Varargs Method Invocation: esto no supone un cambio en la programación, aquí lo que pasa es que si teníamos un método con parámetros de tipo
vararg, si metías tipos no
reifiables (no sé la traducción de
reifiable), daba un warning donde se llamaba a la función y ahora se produce en la declaración de dicha función:
Hasta ahora:
static <T> List<T> asList(T... elements) { ... }
static List<Callable<String>> stringFactories() {
Callable<String> a, b, c;
...
*// Warning: **"uses unchecked or unsafe operations"*
return asList(a, b, c);
Con JDK7.0
*// Warning: **"enables unsafe generic array creation"*
static <T> List<T> asList(T... elements) { ... }
static List<Callable<String>> stringFactories() {
Callable<String> a, b, c;
...
return asList(a, b, c);
}
pues eso, que si veis warnings donde declarasteis vuestros métodos con parámetros vararg y con tipos no reifiables que no os extrañeis.
An amnibus proposal for better integral literals: este cambio combina dos propuestas que añadiran nuevas formas de escribir literales enteros, literales binarios y subrayados en números.
El primero propone que escribas los literales binarios del modo 0b101 o 0B101.
El segundo te ofrecerá la posibilidad (es opcional) poner subrayados en números para hacerlos más legibles, por ejemplo 9_223_312_123_345_786_343L. Language support for Collections: Este es otra combinación de dos propuestas, literales de Collection y sintaxis de acceso a la indexación de Lists y Maps.
Permitirá utilizar expresiones para inicializar nuevas Lists, Sets y Maps de una forma más concisa, por ejemplo:
Hasta ahora:
final List<Integer> piDigits = Collections.unmodifiableList(Arrays.asList(3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 9 ));
será del siguiente modo:
final List<Integer> piDigits = [3, 1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 9];
Si quieres un Set, usa llaves:
final Set<Integer> primes = { 2, 7, 31, 127, 8191, 131071, 524287 };
Hasta ahora un mapa se inicializaba así:
final Map<Integer, String> platonicSolids;
static {
solids = new LinkedHashMapfinal Map<Integer, String> platonicSolids = { 4 : "tetrahedron", 6 : "cube",
8 : "octahedron", 12 : "dodecahedron", 20 : "icosahedron" };
Language support for JSR 292: JSR292 está enfocado en soportar dinámicamente lenguajes tipados en la plataforma Java. Esto cambia el lenguaje para que éstas características estén disponibles desde Java. Por ejemplo esta propuesta podría permitirte invocar dinámicamente cuialquier método en una variable de tipo java.dyn.Dinamic. Esto siempre compilará. En tiempo de ejecución si el método existe, la invocación se realizará:
Dynamic x = (aquí puede haber cualquier tipo de expresión);
Object y = x.foo("ABC").bar(42).baz()
No sé si aquí están queriendo decir que se pueden hacer closures.
Cambios descartados por el momento: Improved Exception Handling for Java: esto es capturar varias excepciones en un solo catch:
try {
doWork(file);
} catch (final IOException|SQLException ex) {
logger.log(ex);
* throw ex;*
}
- ?: este es el elvis, si lo que hay a la izquierda es null, se evalua lo de la derecha.
- variablenull ?: "es null!!"
- ?. este funciona como el punto, pero si lo que hay a la izquierda es null, no se hace nada:
- variable?.toString() // si variable es null, devuelve null
- Luego tendríamos algo como variable?.toString() ?: "variable vacía"
- ?[] para arrays, lo típico, si es null devuelve null
- Luego tendríamos algo como array?[1].nombre?.toString() ?: "algo está a null"
Large Arrays: esto era cambiar el tamaño del índice de los arrays, actualmente de 32bit a 64bit.
Un saludo!
Las fuentes:
http://blogs.sun.com/darcy/entry/project_coin_final_five
http://www.artima.com/forums/flat.jsp?forum=270&thread=266751
