Ya nos hemos acostumbrado al hecho de que aparece una nueva versión de JDK cada seis meses. Hasta ahora, este enfoque se ha justificado, y las preocupaciones de algunos desarrolladores de que no estarán al día con las actualizaciones han sido en vano: hay pocos cambios semestrales y no son tan globales como antes. Bueno, es posible que los programadores novatos no noten la innovación en absoluto. Sin embargo, es mejor para los futuros desarrolladores de software mantenerse al tanto de las innovaciones. En este artículo, describiremos tradicionalmente las propuestas de extensión aceptadas (JEP). Java 13 incluye sólo cinco JEP y 76 nuevos elementos centrales de la biblioteca (de los cuales casi la mitad son simples adiciones al paquete java.io).
Comencemos cambiando la sintaxis del idioma. Los más importantes son los bloques de texto. Le permiten evitar caracteres de escape y saber cómo formatear cadenas. Quizás recuerde que JDK 12 no incluía la característica esperada de Literales de cadena sin formato (JEP 326) para trabajar con literales de cadena. En Java 13, fue reemplazado por JEP 355 con sus bloques de texto. Probablemente recuerdes que en Java, una cadena está entre comillas dobles. Esto es bueno, pero el problema es que una línea no puede ocupar más de una línea del archivo fuente (para evitar confusión con una línea de Java, aquí llamaremos “línea” a una línea de archivo). Bueno, vamos a usar, por ejemplo, el símbolo \nsi se requiere una ruptura o una concatenación de expresiones multilínea. ¡No sale muy bien! Los literales de texto con fragmentos HTML, XML, SQL o JSON incrustados son especialmente engorrosos. Todo este escape, concatenación y edición manual hace que el código sea incómodo de escribir y difícil de leer. Los bloques de texto intentan resolver este problema. Comienzan eh... con comillas dobles triples y terminan con ellas (lo sé, no suena muy bien). Todo lo que está entre comillas se interpreta como parte de la línea, incluidas las nuevas líneas. Los bloques de texto se pueden usar exactamente igual que los literales de texto estándar, y Java compilará el código de la misma manera. Las comillas de apertura deben ir seguidas de un delimitador de línea; Los bloques de texto no se pueden usar en una línea, por lo que el código
String smallBlock ="""Only one line""";
dará lugar a los siguientes errores:
TextBlock.java:3: error: illegal text block opendelimiter sequence, missing line terminator
String smallBlock ="""Text Block""";^TextBlock.java:3: error: illegal text block opendelimiter sequence, missing line terminator
String smallBlock ="""Text Block""";^
Ahora se puede escribir un fragmento HTML simple así:
Mencionemos algunas sutilezas que es mejor tener en cuenta al utilizar bloques de texto. La ubicación de las comillas finales resulta importante: determina cómo se manejan los espacios en blanco ocasionales. En el ejemplo anterior, las comillas finales están alineadas con la sangría del texto HTML. En este caso, el compilador eliminará los espacios de sangría y, como resultado, obtendremos una línea como esta:
<html><body><p>My web page</p></body></html>
Nota:dicha línea contendrá una nueva línea al final de la línea. Si no es necesario, las comillas de cierre “”” se pueden colocar directamente después de la etiqueta </html>. Si acercamos las comillas de cierre al margen izquierdo, esto cambiará la cantidad de sangría eliminada. Si los moviéramos dos espacios hacia la izquierda, agregaríamos dos espacios para sangría a cada línea. Moverse hacia el borde izquierdo hará que se conserve todo el relleno. Mover las comillas más hacia la derecha no tendrá ningún efecto y no agregará más sangría. Los bloques de texto se incluyeron en JDK 13 como función de vista previa. Esto significa que aún no están incluidos en la especificación del lenguaje Java correspondiente. Es decir, no está claro si esta característica se convertirá en una parte permanente del idioma o si será solo una invitada aquí. Actualmente, los desarrolladores pueden probar la función y dar su opinión al respecto. El destino de los bloques de texto dependerá de ello: la función se puede mejorar y, si no te gusta, se puede eliminar por completo. Si desea probar bloques de texto en la práctica, recuerde que las funciones de vista previa deben incluirse explícitamente para poder compilar y ejecutar. Compilacion:
Para ejecutar la aplicación, debe habilitar las funciones de vista previa:
java --enable-preview TextBlock
La clase Stringtiene tres nuevos métodos que complementan este cambio de lenguaje:
formatted(): formatea una cadena utilizando la propia cadena como cadena de formato. Equivalente a un desafíoformat(this, args)
stripIndent(): Elimina espacios aleatorios de una cadena. Esto es útil si está leyendo cadenas de varias líneas y desea aplicar la misma exclusión de espacios en blanco que lo haría con una declaración explícita.
translateEscapes(): Devuelve una cadena con secuencias de escape (como \ r), traducidas al valor Unicode apropiado.
Es interesante que estos métodos acaban de aparecer, pero ya están marcados como obsoletos ... esta situación sugiere que pueden eliminarse en una versión futura del JDK. Parece un poco excéntrico agregar un nuevo método y abandonarlo inmediatamente. Sin embargo, tenga en cuenta que estos métodos están asociados con una función de vista previa que se puede cambiar o eliminar. Quizás introducir una anotación @PreviewFeatureayudaría en tales situaciones, pero aún no está incluida en el JDK (aunque con un alto grado de probabilidad aparecerá en JDK 14).
Java 12 introdujo una propuesta para una nueva forma de escribir expresiones con una declaración de cambio: JEP 325 . Resultó ser la primera función de vista previa y su destino demuestra que enviar propuestas a los usuarios es una gran idea. Antes de JDK 12, switchsolo podía usarse como una declaración que realiza una acción pero no devuelve un resultado. Pero en Java 12 permitía usarlo switchcomo una expresión que devuelve un resultado que se puede asignar a una variable. Hubo otros cambios en la sintaxis de las declaraciones de casos dentro de switch. Veamos un ejemplo de JEP para entender cómo funciona.
En este ejemplo, usamos value dayOfWeekpara asignar el valor a numberOfLetters. Debido a las peculiaridades del trabajo del operador switch, este código no es el más bonito y es fácil cometer errores. Primero, si olvidamos aplicar una declaración breaka cada grupo de etiquetas de casos, pasaremos de forma predeterminada al siguiente grupo de etiquetas de casos. Esto puede provocar errores difíciles de encontrar. En segundo lugar, debemos definir cada grupo de etiquetas de casos. Si lo olvidamos, por supuesto, obtendremos un error del compilador; sin embargo, esta opción no es la ideal. Nuestro código también es bastante detallado porque cada valor dayOfWeekdebe tener su propia etiqueta de caso. Usando la nueva sintaxis, obtenemos un código mucho más limpio y menos propenso a errores:
Ahora solo necesitamos realizar la asignación una vez (a partir del switchvalor de retorno de la expresión) y podemos usar una lista separada por comas para las etiquetas de los casos. Y, al no utilizar el operador break, eliminamos los problemas asociados al mismo. La sintaxis de expresión switchnos permite usar una sintaxis de estilo antiguo, por lo que en JDK 12 podemos escribirla así:
int numberOfLetters =switch(dayOfWeek){case MONDAY:case FRIDAY:case SUNDAY:break6;case TUESDAY
break7;case THURSDAY
case SATURDAY
break8;case WEDNESDAY
break9;default:thrownewIllegalStateException("Huh?: "+ day);};
Según la comunidad Java, utilizar la sobrecarga breakpara especificar un valor de retorno puede resultar confuso. El lenguaje Java también le permite usar break(y continue) con una etiqueta como el operador de salto incondicional goto. JEP 354 cambió este uso break, por lo que en Java 13 nuestro código cambia ligeramente:
int numberOfLetters =switch(dayOfWeek){case MONDAY:case FRIDAY:case SUNDAY:yield6;case TUESDAY
yield7;case THURSDAY
case SATURDAY
yield8;case WEDNESDAY
yield9;default:thrownewIllegalStateException("Huh?: "+ day);};
Los siguientes tres JEP están asociados con la máquina virtual Java.
Esta extensión le permite archivar clases dinámicamente al final de la ejecución de una aplicación Java. CDS o Class Data Sharing le permite empaquetar todas las clases iniciadas al inicio en un archivo especial class data sharing, utilizando la lista de estas mismas clases de forma predeterminada. Esto conduce a una aceleración significativa en el inicio de aplicaciones y al ahorro de RAM. Anteriormente, usar AppCDS era un proceso de varios pasos que implicaba crear una lista de clases relevantes y usar esa lista para crear un archivo que se usaría para ejecuciones posteriores. Ahora todo lo que se requiere es iniciar la aplicación con el indicador -XX: ArchiveClassesAtExitque indica la ubicación donde se escribirá el archivo. Con este enfoque, las clases se empaquetan automáticamente en un archivo después de que la aplicación se detiene normalmente.
JEP 351 ZGC : no confirmar la memoria no utilizada
Hace un año, JDK 11 presentó ZGC, un recolector de basura experimental, escalable y de baja latencia. Al principio, ZGC se comportó de manera bastante extraña: no permitía devolver la memoria al sistema operativo, incluso si ya no era necesaria. Para algunos entornos, como los contenedores, donde varios servicios utilizan recursos al mismo tiempo, esto puede limitar la escalabilidad y eficiencia del sistema. El montón ZGC consta de las denominadas ZPages. Cuando las ZPages se borran durante el ciclo de recolección de basura, se devuelven a ZPageCache. Las ZPages en este caché están ordenadas según la fecha de uso. En Java 13, ZGC devolverá al sistema operativo las páginas que se hayan identificado como no utilizadas durante mucho tiempo. De esta forma se pueden reutilizar para otros procesos.
Ambas implementaciones de API siguen java.net.Socketsiendo java.net.ServerSocketJDK 1.0. En este y en todos los JDK posteriores, la implementación de estas API utiliza varias técnicas (como el uso de la pila de subprocesos como un búfer de E/S) que las hacen inflexibles y difíciles de mantener. Para resolver este problema, se proporcionó una nueva implementación en JDK 13 NioSocketImpl. Ya no requiere código nativo, lo que facilita la migración a diferentes plataformas. Esta clase también utiliza el mecanismo de caché del búfer existente (evitando el uso de la pila de subprocesos para este propósito) y java.util.concurrentmétodos de bloqueo en lugar de sincronizados. Esto simplificará la integración con fibras de Project Loom .
Nuevas API
Mencionamos anteriormente que Java 13 incluye 76 API nuevas en las bibliotecas de clases base. Cubren las siguientes áreas:
Actualizaciones de soporte Unicode.
Tres nuevos métodos Stringpara admitir bloques de texto (consulte la descripción de JEP 255 más arriba).
Las clases java.nioahora tienen valores absolutos (a diferencia de relativos) gety
establecer métodos. Ellos, al igual que la clase abstracta base
Buffer, incluyen un método
slice()para recuperar parte del búfer.
El método force()de clase MappedByteBufferfuerza que se escriba una sección del búfer en su almacenamiento de respaldo.
nio.FileSystemAgrega tres nuevas formas sobrecargadas newFileSystem()para acceder al contenido de un archivo como un sistema de archivos.
Ha javax.annotation.processing.ProcessingEnvironmentaparecido un nuevo método interesante. isPreviewEnabled(). Le indicará si las funciones de vista previa están habilitadas. Esto es interesante porque la anotación mencionada anteriormente @PreviewFeatureno estará disponible hasta que se lance JDK 14.
DocumentBuilderFactoryy SAXParserFactoryobtenga javax.xml.parserstres nuevos métodos para crear instancias con reconocimiento de espacios de nombres.
GO TO FULL VERSION