kompilatory: microsoft vs jrockit

ale buba :)

zwróć uwagę na podwójną annotację "deprecated" w poniższym listingu:

public class Deptest {

/**
* @deprecated aasadsa
* @deprecated sddsfsdf
*/
public String hello() {
return "hello";
}

public static void main(String[] args) {
Deptest t = new Deptest();
System.out.println(t.hello());
}
}

okazuje się, że ten kod skompilowany kompilatorem Microsoftu (tak, jest taki kompilator...) nie zadziała w środowisku uruchomieniowym JRockit firmy Bea (Oracle). Wygenerowany zostanie błąd ClassFormatException:

D:\Programy\Java\bea102\jrockit_150_11\bin>java Deptest
Exception in thread "Main Thread" java.lang.ClassFormatError: Deptest :
duplicate attribute Deprecated
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at
java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)

Ciekawa sprawa - ten sam kod działa w środowisku JRE Suna. Dlaczego tak jest? Otóż okazuje się, że JRockit o wiele bardziej restrykcyjnie sprawdza poprawność bytecodu plików .class.

Poradzić sobie z tym problemem można na dwa sposoby:
1) usunąć podwójną annotację i przekompilować klasę
2) uruchomiająć środowisko JRockit (np. serwer weblogic) użyć przełącznika-Xverify, który wyłączy wspomnianą restrykcyjną politykę JRockit.