jikes-1.21 kompiliert nicht mit JDK 1.5.0
-
Salut,
eigentlich habe ich meinen Java-Code immer mit Jikes-1.21 von IBM in Verbindung mit dem J2EE 1.4 kompiliert. Als Editor habe ich den JCreator LE (Version 2.5 build 9) benutzt, als OS habe ich Win2K.
Auch mit dem J2SE hat immer alles geklappt, aber seit dieser Woche habe ich das JDK 1.5.0 installiert und jetzt geht Jikes auf einmal nicht mehr.
Jikes ist bei mir als Custom Tool folgendermaßen eingerichtet:
Command: F:\Compiler\jikes-1.21\bin\jikes.exe
Arguments: -bootclasspath F:/Compiler/jdk1_5_0/jre/lib/rt.jar -O $[FilePath]
Initial Directory: $[FileDir]Beim kompilieren dieses simplen Quelltextes mit jikes-1.21 und dem JDK1.5 als Grundlage erscheint nachfolgende Fehlermeldung, mit dem JDK1.5 direkt, oder dem J2EE 1.4 mit oder ohne jikes geht alles perfekt:
import java.awt.*; import java.awt.event.*; import javax.swing.*; public class SplitPaneTest extends JFrame { public SplitPaneTest() { initComponents(); } private void initComponents() { setSize(400,512); setResizable(false); setTitle("Test of Swing Component JSplitPane"); LbLeft = new JLabel(new javax.swing.ImageIcon("Picture1.jpg")); LbLeft.setMinimumSize(new Dimension(50, 20)); LbRight = new JLabel(new javax.swing.ImageIcon("Picture2.jpg")); LbRight.setMinimumSize(new Dimension(50, 20)); split = new JSplitPane(JSplitPane.HORIZONTAL_SPLIT, LbLeft, LbRight); split.setContinuousLayout(true); split.setOneTouchExpandable(true); split.setDividerLocation(200); getContentPane().add(split, BorderLayout.CENTER); addWindowListener(new WindowAdapter() { public void windowClosing(WindowEvent evt) { setVisible(false); System.exit(0); }}); } public static void main(String args[]) { new SplitPaneTest().setVisible(true); } protected JLabel LbLeft, LbRight; protected JSplitPane split; }--------------------Custom Tool: jikes-------------------- Found 15 semantic errors compiling "F:/Programmierung/Java/Swing/JSplitPane/SplitPaneTest.java": 5. public class SplitPaneTest extends JFrame { ^----^ *** Semantic Error: The class file "Frame.class" in "F:\Compiler\jdk1_5_0\jre\lib\rt.jar\java\awt" has an invalid format (bad type for annotation). 11. setSize(400,512); ^--------------^ *** Semantic Error: No accessible method with signature "setSize(int, int)" was found in type "SplitPaneTest". 12. setResizable(false); ^-----------------^ *** Semantic Error: No accessible method with signature "setResizable(boolean)" was found in type "SplitPaneTest". 13. setTitle("Test of Swing Component JSplitPane"); ^--------------------------------------------^ *** Semantic Error: No accessible method with signature "setTitle(java.lang.String)" was found in type "SplitPaneTest". 15. LbLeft = new JLabel(new javax.swing.ImageIcon("Bikini1.jpg")); ^----^ *** Semantic Error: A candidate for type "JLabel" was found, but it is invalid and needs to be fixed before this type will successfully compile. 18. LbRight = new JLabel(new javax.swing.ImageIcon("Bikini2.jpg")); ^----^ *** Semantic Error: A candidate for type "JLabel" was found, but it is invalid and needs to be fixed before this type will successfully compile. 21. split = new JSplitPane(JSplitPane.HORIZONTAL_SPLIT, LbLeft, LbRight); ^--------^ *** Semantic Error: A candidate for type "JSplitPane" was found, but it is invalid and needs to be fixed before this type will successfully compile. 27. getContentPane().add(split, BorderLayout.CENTER); ^----------^ *** Semantic Error: The class file "BorderLayout.class" in "F:\Compiler\jdk1_5_0\jre\lib\rt.jar\java\awt" has an invalid format (bad type for annotation). <-------------------------------------- 29. addWindowListener(new WindowAdapter() { . . . 33. }}); ------------------> *** Semantic Error: No accessible method with signature "addWindowListener(SplitPaneTest.1)" was found in type "SplitPaneTest". 31. setVisible(false); ^---------------^ *** Semantic Error: No accessible method with signature "setVisible(boolean)" was found in type "SplitPaneTest$1". 32. System.exit(0); ^----^ *** Semantic Error: The class file "System.class" in "F:\Compiler\jdk1_5_0\jre\lib\rt.jar\java\lang" has an invalid format (bad type for annotation). 36. public static void main(String args[]) { ^----^ *** Semantic Error: The class file "String.class" in "F:\Compiler\jdk1_5_0\jre\lib\rt.jar\java\lang" has an invalid format (bad type for annotation). 37. new SplitPaneTest().setVisible(true); ^----------------------------------^ *** Semantic Error: No accessible method with signature "setVisible(boolean)" was found in type "SplitPaneTest". 40. protected JLabel LbLeft, LbRight; ^----^ *** Semantic Error: The class file "JComponent.class" in "F:\Compiler\jdk1_5_0\jre\lib\rt.jar\javax\swing" has an invalid format (bad type for annotation). 41. protected JSplitPane split; ^--------^ *** Semantic Error: A candidate for type "JSplitPane" was found, but it is invalid and needs to be fixed before this type will successfully compile. Process completed.Die ganzen Verzeichnisse sind richtig geschrieben und alles deutet darauf hin dass Sun beim JDK 1.5.0 die Datei rt.jar erheblich umgebaut hat, denn wenn ich ein mit dem J2EE1.4 und jikes kompiliertes Projekt mit dem JDK 1.5 interpretieren will geht gar nix.
Falls jemand dieses Problem schon gelöst hat wäre ich für Hilfe dankbar.Mfg
GPC
-
Dein Jikes versteht halt noch kein Java 5.0. Nutz doch einfach den normalen Javacompiler, bis Jikes eine entsprechende Unterstützung bietet.
-
Na ja, in dem Fall heißt's wohl warten und Tee trinken.
-
Der Eclipse Compiler ist doch auch von IBM oder?
Der versteht Java 1.5 eigentlich schon zu 99%. Mir ist noch gar nichts aufgefallen, was irgendwie nicht gepasst hätte.
-
schon, aber ich mag kein Eclipse. Ich bleib bei meinem JCreator. Schneller
-
JCreator rult!
-
Ähm, wenn ich mich nicht täusche, beherrscht der nicht mal das einfachste Refactoring. Das rult dann aber nicht so wahnsinnig.
-
Sgt. Nukem schrieb:
JCreator rult!
das würdest du nicht schreiben, wenn du dir mal 'intellij idea' oder 'oracle jdeveloper' angesehen hättest
-
Kenn' ich beide.
Letzteres ist aufgrund der Startzeit für mich schon absolut unbrauchbar.Intelli ist ziemlich genial - kostet aber.
-
Optimizer schrieb:
Ähm, wenn ich mich nicht täusche, beherrscht der nicht mal das einfachste Refactoring. Das rult dann aber nicht so wahnsinnig.
ok, das stimmt schon so. Aber kleine Geschichte: Als ich begann zu proggen hab ich das mit VB 6.0 getan, und wie man weiß kann man da so gut wie alles in dem GUI-Designer machen. Logo, war komfortabel aber eben null Kontrolle, so von wegen mal im Source was ändern.
Dann kam Java und die Ernüchterung das alles von Hand schreiben zu müssen. Als das am Anfang wegen Motivation nicht so klappte kam der JBuilder her, aber dieses Programm habe ich gehasst wie kein anderes, lahm, unflexibel und auch wenn ich die GUI im Code ändern konnte entstand folgende Regel: Einmal was am vom JBuilder generierten Code geändert und du kannst die Souce wegschmeißen!
Also bin ich dann bei NetBeans 3.5 gelandet welches mir gut gefiel und auch nett zu bedienen war. Nach den Startschwierigkeiten ein Problem, von NB generierter Code kann ich ja gar nicht ändern. Dame!
Dann kam mir durch zufall der JCreator drauf und der konnte eigentlich alles was ich brauchte: Compilieren, Interpretieren (bzw. Ausführen), Externe Tools ausführen, JavaDoc aufrufen und mehr braucht der GPC zum proggen eben nicht.
Mag sein dass ich viel Zeit mit dem Coden der GUI verbringe, aber die ist ausgereift, genauso wie ich sie mir vorstelle, flexibler (ist meine Erfahrung, kann auch abweichen) und vor allem übersichtlich.
Abgesehen davon tippe ich meinen gtkmm Code auch im JEdit ab. Geht wunderbar.Ich mache niemandem einen Vorwurf nur weil er eine IDE benutzt, die können mordspraktisch sein, keine Frage. Aber ich beschränke mich da eben auf's wesentliche.
In diesem Sinne...
-
GPC schrieb:
Dame!
...soll wohl "Damn!
" heissen...
-
Keep it simple, stupid!
-
GPC schrieb:
Also bin ich dann bei NetBeans 3.5 gelandet welches mir gut gefiel und auch nett zu bedienen war. Nach den Startschwierigkeiten ein Problem, von NB generierter Code kann ich ja gar nicht ändern. Dame!
Dann kam mir durch zufall der JCreator drauf und der konnte eigentlich alles was ich brauchte: Compilieren, Interpretieren (bzw. Ausführen), Externe Tools ausführen, JavaDoc aufrufen und mehr braucht der GPC zum proggen eben nicht.
Ich verstehe dich nicht. Du mußt dir doch von Netbeans keinen Code generieren lassen, nur weil das möglich ist. Du kannst es genauso nutzen, wie den JCreator. Dazu kriegst du dann noch solche Features wie Refactoring und ab Dezember auch noch nen tollen integrierten Profiler. Aus meiner Sicht ist Netbeans dem JCreator bei weitem überlegen.
-
Aus meiner Sicht ist Netbeans dem JCreator bei weitem überlegen.
Natürlich. Aber mit Features die kein normaler Hobby Programmierer brauch.
Und langsam...
-
bla bla blub schrieb:
Natürlich. Aber mit Features die kein normaler Hobby Programmierer brauch.
Ich benötige diese Features, die JCreator nicht bietet. ...jeder, der mal ein nicht ganz kleines Programm geschrieben hat, kann Dinge wie Refactoring sehr gut gebrauchen. Das ist unabhängig davon, ob man das als Hobby macht oder nicht.
-
Sgt. Nukem schrieb:
GPC schrieb:
Dame!
...soll wohl "Damn!
" heissen... Nope, dame ist slang für damn
Gregor schrieb:
Ich verstehe dich nicht. Du mußt dir doch von Netbeans keinen Code generieren lassen, nur weil das möglich ist. Du kannst es genauso nutzen, wie den JCreator. Dazu kriegst du dann noch solche Features wie Refactoring und ab Dezember auch noch nen tollen integrierten Profiler. Aus meiner Sicht ist Netbeans dem JCreator bei weitem überlegen.
Stimmt, kann ich machen, aber wenn ich NB wie JCreator benutze, dann kann ich auch gleich JCreator nehmen. Abgesehen davon: Mein letztes Programm (ein Editor mit ca. 5000-6000 Zeilen) hab ich mit dem JCreator ohne Probleme coden können.
Btw. Was ist eigentlích dieses sagenumwobene Refactoring?
-
Was man nicht kennt, vermisst man offenbar nicht. Guckst du mal google oder wikipedia. :p
-
GPC schrieb:
Btw. Was ist eigentlích dieses sagenumwobene Refactoring?
Es geht dabei um das automatische projektweite Ändern von Dingen, die man im Verlauf des Projekts nunmal hin und wieder ändert. Beispielsweise könnte man auf die Idee kommen, dass der Name einer Klasse, einer Methode, einer Membervariable usw. doch nicht so ganz passend ist. Das Refactoring hilft einem dann dabei, sämtliche Vorkommen dieses Namens im Projekt auf einen Schlag automatisch zu ändern. Man muss also nicht stundenlang alles per Hand machen, sondern hat das mit ein paar Mausklicks in Sekunden automatisch erledigt. Das ganze geht natürlich noch etwas weiter als nur beim Umbenennen von irgendwelchen Dingen zu helfen.
-
zugegebernmaßen, scheint echt praktisch zu sein.