Java se está expandiendo con nuevos mecanismos de moda, y con él, su tumba está creciendo con características obsoletas como Vector, Finalization, NashornScriptEngine, SecurityManager y Unsafe. ¿Cómo se llena la tumba? Java prospera y crece, acumulando nuevas características, APIs y módulos, pero al mismo tiempo, elimina su vieja piel de vez en cuando. Algunas partes resultan redundantes, otras ya no se ajustan a las tareas modernas, y algunas siempre están destinadas a ser malditas. Veamos algunos de ellos. ¿Qué hay dentro de la tumba? Colecciones de legado Los días antes de que Java tuviera , de , o y salvajes , de , y A diferencia de todas las antiguidades posteriores, esta API desactualizada no está marcada como , but at the same time, the  Para cada clase grita "¡NUNCA ME USE!" En la inmensidad de Internet, estas clases obsoletas suelen llamarse . List Deque Map Vector Stack Dictionary Deprecated Documentación legacy collection classes ¿Por qué están obsoletos? Las colecciones de legado tienen dos principales desventajas: 
 
 
 todos los puntos de interacción con estas clases se sincronizan; Las clases no tienen interfaces comunes y requieren un enfoque individual. Vamos en orden. La primera desventaja es que** todos los puntos de interacción con estas clases están sincronizados.** Sin embargo, se siente más como una ventaja que lo contrario. Después de todo, el multithreading seguro es siempre una buena cosa. Pero ¿qué pasa si estas colecciones se utilizan en un contexto de un solo hilo? Las sincronizaciones simplemente reducen el rendimiento sin proporcionar ningún beneficio de seguridad real. Esto se refleja claramente en las prácticas modernas de Java, donde los desarrolladores prefieren copiar colecciones en lugar de modificarlas. La segunda desventaja** es que las clases no tienen interfaces comunes y requieren un enfoque individual.** Esto conduce a un problema tan antiguo como la programación en sí: código no universal.Sólo imagina que somos un desarrollador trabajando en una versión antigua de Java, y tenemos código ligado a Por ejemplo, aquí está uno: Stack Stack<Integer> stack = new Stack<>();

for (int i = 0; i < 5; i++) {
    stack.add(i);
}

System.out.println(stack.pop());
 En este momento, el código es sin ningún problema, pero imagínate que se ha acumulado a 1.000 líneas con 150 referencias a la de variable . stack Entonces un día, los clientes nos enviaron un fax, diciendo que trabajaron muy lentamente (los bloques de código, no los clientes). contiene una matriz para almacenar elementos, y esta misma matriz es recreada con demasiada frecuencia. Stack Pensamos y presentamos una teoría: la lista enlazada puede ayudar a aumentar el rendimiento de la aplicación en 100 veces! en Internet, y luego enrollamos nuestras mangas para copiar y refactorar todas las 150 referencias a No en absoluto, pero no vemos otra salida. LinkedList stack Pasemos al presente, donde nuestro código se ve así: Deque<Integer> deque = new ArrayDeque<>();
IntStream.range(0, 5)
        .forEach(deque::addLast);
System.out.println(deque.pollLast());
 Con el tiempo, el código también crece para incluir 150 referencias, pero ahora tiene referencias a Seguimos el mismo camino y también planteamos la teoría de que será más rápido con una lista enlazada. Dos que también implementan ¡Y eso es todo lo que se necesita! deque ArrayDeque LinkedList Deque Esto es exactamente como la resuelto el problema de la falta de interfaces comunes. Ayuda a evitar estar atado a implementaciones específicas. por ejemplo, los desarrolladores ya no están bloqueados en algo como Y puede utilizar el Interface en su lugar. Marco de Colecciones Vector List Finalización En un momento, (en el ) parecía una excelente idea: un método que sería llamado cuando un objeto fue destruido, liberando recursos del sistema. Finalistas #finalize() Pero, en la práctica, esta idea no fue tan brillante: 
 
 
 
 
 El finalista puede no ser llamado en absoluto si todavía había una referencia al objeto en algún lugar o si el colector de basura no quería borrarlo. si el colector de basura quería destruir el objeto, aún tenía que esperar hasta que este código fuera ejecutado; el objeto puede incluso resucitarse a sí mismo; Lo peor de todo, los finalizadores crearon condiciones perfectas para las fugas de memoria. Comencemos de lejos. Java moderna es muy flexible; incluso el colector de basura puede ser de cualquier tipo y configurado de diferentes maneras. Y no olvide que el colector de basura está garantizado para no recoger una instancia siempre que tenga al menos una referencia fuerte. Por estas razones, la lógica de liberar los recursos del sistema no debe depender del ciclo de vida del objeto. Si miramos la documentación de la método, vemos que se recomienda utilizar el interfaz en lugar. Se creó específicamente para liberar eficientemente los recursos sin involucrar al colector de basura. para hacerlo. #finalize() AutoCloseable not to forget En cuanto al seguimiento cuando un objeto es realmente borrado, Java ofrece una alternativa: , which solves the problems described above. java.lang.ref.Cleaner Para la claridad, vamos a jugar con la memoria de Java y escribir algún código inseguro usando un finalizador: class ImmortalObject {  
    private static Collection<ImmortalObject> triedToDelete = new ArrayList<>();

    @Override  
    protected void finalize() throws Throwable {
        triedToDelete.add(this);
    }  
}
 Aquí, resucitamos literalmente cada instancia de que el colector de basura está a punto de borrar, lo que no agradará a su RAM o a usted mismo cuando se colapse con un . ImmortalObject OutOfMemoryError Así es como se ve el código equivalente con : Cleaner static List<ImmortalObject> immortalObjects = new ArrayList<>();

....

var immortalObject = new ImmortalObject();  
Cleaner.create()  
        .register(  
                immortalObject,  
                () -> immortalObjects.add(immortalObject)  
        );
 Vale la pena mencionar que también podemos escuchar la eliminación de absolutamente cualquier objeto existente. ¿Hemos aprendido por qué ese enfoque es problemático? Eso es cierto, pero sólo es malo con la gestión de recursos. A veces una aplicación Java todavía necesita saber que el colector de basura elimina un objeto. La clase sigue viviendo hasta su nombre, pero no porque la añadamos a una lista estática cuando eliminamos la instancia. que actúa como el oyente tiene aquí una referencia a Ahora el objeto no será resucitado porque el colector de basura no borrará la instancia. Es más idiomático en Java y no hay necromancia involucrada. Runnable immortalObject Los finalizadores a menudo se usaban cuando se trabajaban con objetos que fueron creados a través de JNI en algún lugar fuera del código Java, por ejemplo, en C++. Pero el mecanismo era inseguro, y los finalizadores finalmente fueron reemplazados por una alternativa mucho más elegante. NashornScriptEngine Pocos recuerdan que Java una vez literalmente mantuvo el ritmo con JavaScript: JDK 8 presentó el El motor JS, que permite a los desarrolladores ejecutar código JS directamente desde Java. Nashorn Podríamos implementar ese popular rompecabezas de plátano sin dejar Java: new NashornScriptEngineFactory()
        .getScriptEngine()
        .eval("('b' + 'a' + + 'a' + 'a').toLowerCase();");
 De hecho, es una cosa cool, pero solo hasta que nos damos cuenta de que los desarrolladores de Java tienen que mantener el motor JavaScript. Nashorn no pudo seguir el ritmo con la rápida evolución de JavaScript, así como las soluciones poliglot aparecieron, como GraalVM Polyglot. Estos factores llevaron al motor a quedarse obsoleto después de sólo cuatro versiones de idiomas (en Java 11), y después de un tiempo, finalmente fue En Java 15. Lanzado sobre el barco Why is GraalVM Polyglot better? While Nashorn has implemented JavaScript on top of Java, Polyglot creates an entire JVM-based platform that natively supports multiple languages, including Java and JavaScript. Administrador de Seguridad Conoce otro antiguo temporizador que sobrevivió hasta Java 17. . SecurityManager En los días de los applets salvajes, cuando el código Java podía ejecutarse directamente en el navegador, Es la base de la seguridad de aplicaciones Java. SecurityManager 
 
 Un applet es un pequeño programa que se ejecuta directamente en un navegador y puede mostrar animaciones, gráficos o elementos interactivos, pero funciona bajo estrictas limitaciones. Un applet es un pequeño programa que se ejecuta directamente en un navegador y puede mostrar animaciones, gráficos o elementos interactivos, pero funciona bajo estrictas limitaciones. Pero el tiempo pasa, salvaje finalmente migró de los navegadores a los escritorios, y luego murió completamente como una solución. A menudo se utiliza en aplicaciones empresariales. aplausos SecurityManager y Pero nada dura para siempre, y el Grim Reaper vino para Java 17 eliminó todo su interior y sólo dejó la fachada sin ninguna lógica. Sólo encontraremos el lugar: SecurityManager SecurityManager @Deprecated(since = "17", forRemoval = true)
public static void setSecurityManager(SecurityManager sm) {
    throw new UnsupportedOperationException(
             "Setting a Security Manager is not supported");
}
 Entrar en modo de pantalla completa Salir en modo de pantalla completa Cómo hizo Funcionó como un guardián interno de JVM que interceptó operaciones potencialmente peligrosas y comprobó si cada elemento de la pila tenía el derecho de realizar tal acción. SecurityManager Lo que exactamente hizo La lista es enorme, por lo que sugiero que sólo echemos un vistazo a los puntos principales: SecurityManager 
 
 
 
 
 
 Acceso al sistema de archivos; las conexiones de red; Crear y completar procesos; Acceso a las propiedades del sistema; Manipulación de clases y reflexión. Funcionó bien en los días de los applets del navegador, donde era necesario mantener el código no confiable en una caja de arena, pero con el desarrollo de la containerización, se volvió obsoleto. SecurityManager Aunque originalmente fue creado para applets, también se utilizó en otros contextos. En nuestro analizador estático PVS-Studio, ayudó a resolver un problema divertido: si el inicializador de clase estática en el código analizado llamado El proceso de análisis terminaría.  allowed us to block such operations when analyzing static fields, and something we later replaced with ASM. SecurityManager Apoyado System#exit SecurityManager Por cierto, aunque applets como un enfoque fueron descontinuados antes de , que apenas han comenzado a ser eliminados de la JDK. SecurityManager El mundo está cambiando, los enfoques están cambiando y está saliendo. SecurityManager inseguridad Java removes unsafety. Literally. Tal vez el más legendario residente de esta tumba fue . sun.misc.Unsafe Esta clase era una puerta de entrada secreta a las profundidades de JVM, donde las reglas de idioma habituales ya no estaban en vigor. Puede desactivar fácilmente una aplicación Java . Unsafe SIGSEGV ¿Cómo? por ejemplo, como esto: class Container {
    Object value; // (1)
}

// ✨ some magic to get unsafe unsafely ✨
Unsafe unsafe = ....;

long Container_value =
  unsafe.objectFieldOffset(Container.class.getDeclaredField("value"));

var container = new Container();

unsafe.getAndSetLong(container, Container_value, Long.MAX_VALUE); // (2)
System.out.println(container.value); // (3)
 En la campo (1), hemos establecido 2) En lugar de y trate de extraer el valor a 3 ) value Long.MAX_VALUE Object System.out La máquina virtual no le gusta este truco, y se estrella en la última línea porque contiene basura en lugar de una referencia real al objeto, y este es solo un ejemplo de un error tan fácil de detectar. value Pero ¿por qué se agregó un mecanismo tan peligroso a Java? No nació como anarquista, sino como salvador.  and  (hablaremos de ellos más adelante), las bibliotecas estándar tuvieron que realizar operaciones de bajo nivel como la gestión de la memoria, las operaciones atómicas o el bloqueo de hilo de manera eficiente. Unsafe VarHandle MemorySegment Pero ¿cómo podemos hacer todo lo anterior si el lenguaje te prohíbe mirar debajo del capó? Apareció como un herramientas para las necesidades propias de Java. Unsafe internal Los desarrolladores tenían la intención de usarlo sólo dentro de Java, e incluso tenía protección contra el acceso externo a su instancia. Pero lo que sucedió en Java, no se quedó en Java, y los desarrolladores encontraron una manera de obtener Mira la magia que captura una "inseguridad" de una manera insegura: Unsafe var Unsafe_theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
Unsafe_theUnsafe.setAccessible(true);
Unsafe unsafe = (Unsafe) Unsafe_theUnsafe.get(null);
 Este objeto nos permite torturar la máquina virtual tanto como queramos. Pero no te apresures a criticar a los desarrolladores que se atrevieron a alcanzar lo que Java trató de ocultar de ellos; vale la pena recordar: el acceso a ayudó a que muchas bibliotecas se hicieran más eficientes. Por ejemplo, la popular biblioteca Netty para trabajar con redes se vio obligada a utilizar Y cuando un reemplazo salió, Netty de la misma. Unsafe Unsafe Cambio ¿De qué tipo de sustitución estamos hablando? No hay uno, sino dos: 
 
 
 La API de funciones y memoria extranjeras reemplaza las operaciones de memoria. VarHandle API sustituye las operaciones atómicas. Estas APIs no se limitan a simplemente reemplazar ciertos métodos en Son herramientas poderosas para trabajar de forma segura con operaciones de bajo nivel. Por ejemplo, la API de Función y Memoria Extranjera permite llamar funciones nativas sin utilizar el complicado JNI! Unsafe La inseguridad de Java está lentamente desapareciendo en el olvido, dejando atrás nuevas, bien diseñadas y potentes APIs que hacen lo mismo sin temor a la condicionalidad. . SIGSEGV ¿Por qué la tumba está llena? Java está creciendo, derramando ideas obsoletas, convirtiéndose en más seguras, limpias y sencillas.Cada nueva API no es simplemente "añadir otro módulo", sino cerrar las antiguas lagunas de una manera más sofisticada. Al mismo tiempo, la “tumba” virtual juega un importante papel cultural: registra la evolución de las ideas y decisiones, nos recuerda el camino que hemos recorrido y forma el contexto necesario para el desarrollo de una plataforma significativa.

Read My Stories

Este audio es producido en el idioma original de la historia!

El cementerio creciente de Java: las viejas APIs que están siendo enterradas - y lo que las sustituyó

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Telegram: el puente de Crypto Island hacia el continente

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

Telegram: el puente de Crypto Island hacia el continente

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps