sistemas - convertir de decimal a binario octal y hexadecimal en java

¿Qué pasó con la compatibilidad binaria de Java?

Question

Me encontré con un antiguo conjunto de clases con fecha de marzo de 1997. Fue durante el tiempo en que intenté aprender Java, y era JDK 1.0.2.

Curiosamente, tengo los archivos de origen y los archivos de clase intactos desde ese momento. Las fuentes aún se compilan y ejecutan como se esperaba, lo que fue realmente genial. ¿Pero no se suponía que Java debía conservar la compatibilidad binaria también? Bueno, en algún punto del camino, el formato ya no es válido. Un Java 8 VM informará;

Exception in thread "main" java.lang.ClassFormatError: Invalid start_pc 65535 in LocalVariableTable in class file bali/core/Application
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:455)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
    :
    [snip many ClassLoader calls]
    :
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)

La clase ofensiva es la superclase de la clase a la que llamo desde la línea de comando.

Un detalle más, en esos días, Microsoft todavía estaba en el campamento de Java, y recuerdo que su javac era más compatible con la sintaxis mal escrita. El compilador de Sun con mucho gusto aceptaría "clase sincronizada pública Abc" y muchas otras declaraciones no válidas. Por lo tanto, existe una gran posibilidad de que estos archivos de clase hayan sido generados por el compilador de MS y luego ejecutados en Sun JVM.

De todos modos, mi pregunta es; ¿Hay alguien alrededor que tenga conocimiento sobre el compromiso de compatibilidad en las primeras versiones de Java? ¿Fue un gran problema, o fue sacrificado a propósito? ¿O hubo una decisión mucho más tarde, digamos Java 1.4 o Java 5 para simplemente abandonar el soporte JDK 1.0?

Answer 1

Como mencionó, el problema probablemente se presentó cuando el compilador cambió del compilador de Microsoft al compilador de Sun. Sun declaró que los archivos de clase generados por el compilador de Microsoft no seguían la especificación de Java y, por lo tanto, no eran válidos.

Puedes encontrar más detalles here :

Este error se debe a un código de bytes generado a partir de antiguos compiladores JDK 1.0.2 o 1.1. En el pasado, muchos de estos compiladores generaban un código de bytes que no se ajustaba a la especificación de Java VM. Dado que los verificadores en las versiones recientes de J2SE son mucho más estrictos con respecto al formato de clase incorrecta, la VM lanza la ClassFormatError cuando se cargan estos archivos de clase incorrecta.

Con respecto a la pregunta general, Java todavía está firmemente comprometido con la compatibilidad con versiones anteriores y nunca ha habido una ruptura importante. Por lo general, hay pequeñas interrupciones desde la publicación hasta la liberación en cuestiones complementarias. No conozco ninguna tabla maestra pero aquí hay tablas para versiones individuales:

• Java 8 (totalmente binario compatible con Java 7)
• Java 7 (mayormente binario compatible con Java 6)
• Java 6 (en su mayoría binario compatible con Java 5, más un comentario de que algunos ofuscadores generaron archivos de clase fuera de la especificación y, por lo tanto, es posible que esos archivos de clase no se ejecuten)
• Java 5 (en su mayoría binario compatible con Java 1.4.2, más el mismo comentario sobre ofuscadores)
• Java 1.0 - 1.4.2 (en su mayoría binarios compatibles con versiones anteriores, algunos comentarios que dicen que la compatibilidad hacia adelante puede funcionar pero no se han probado)