Werden die SUN JVMs immer blöder oder was soll das.

[thE_29]

Also, ein Arbeitskollege, was net wirklich Java programmiert (C/C++) hat da so ein Programm was ihm unsere Linzer Kollegen geschickt haben.

Jedenfalls er will das Programm starten und es geht nicht. Bekommt immer eine NoClassDefFoundError!

Ich zu ihm, du musst den Classpath setzen oder direkt angeben, geben wir ihn aber lieber direkt an.


Gesagt getan, die BatchDatei sieht so aus:

@java -cp loader.jar;service.jar;jta20.jar;resource.jar;shared.jar;gui.jar loader/SafeService


So, ich starte das Ding auf meinem PC und schwups das Programm startet!

Danach probiert er es auf seinem PC und es geht NICHT!

Ich, hö?? Das kanns jetzt aber net sein..

Naja, vielleicht hats ja was mit der version zum tun!

Ich hatte diese Version

java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)


Er hat die 1.4.2_06-b03 oder sowas!

Anscheinend gehts dann nicht mehr (warum ist halt ne andere Frage...)

Jedenfalls, wenn ich es mit einer 1.4.1_02-b06 mache geht es auch!

Nur nicht mit höheren 1.4.2_06 und mit 1.5 gehts schon gar nicht...

(hier ein kleiner Screenshot: http://members.aon.at/taschek/jvmtroubles.jpg )

Mir ist dies nun schon öfters aufgefallen (vorallem bei Linux JVM) das manche Dinge in einer niedrigeren Vesion der JVM funktionierten und bei höheren nicht mehr..


Nun die Frage, was tun die bitte??? Warum gehn manche Dinge bitte nicht mehr mit höheren Versionen (und wenn es nur mit 1.5 nicht ginge, würde ich es noch ein bißchen verstehen, aber net mal mit einer 1.4er).

In letzter zeit, macht Sun meiner Meinung nur noch scheisse und Java tendiert sowieso immer mehr zu einem C++ Klon nur Systemunabhängiger als C (bin ja gespannt was in Java 6 noch kommt, warte nur noch bis man Operatoren überladen kann...)

Jedenfalls finde ich das eher komisch und irgendwo sinnlos, das aufeinmal Dinge nicht mehr funktionieren nur weil die jvm Version höher ist (super für die, die immer Updaten... Aufeinmal gehen die Programme nicht mehr...)


Naja, er muss sich jetzt ne ältere JVM rauftun und dann gehts, aber was soll der Blödsinn halt..

 

[L-ectron-X]

Vielleicht liegt ja gar nicht an der Java-VM. Ich kann das irgendwie nicht glauben.
Vielleicht variiren nur eure Systeme?

 

[thE_29]

Das Bild ist auf meinem System gemacht worden!

Siehs dir an, mit den 2 1.4 JDKs gehts, mit der 1.5er nicht mehr...

Und so verschieden, können die Systeme net sein, da ja der Aufruf via batchdatei erfolgt und da sollte das dann trotzdem klappen!

 

[L-ectron-X]

Schreibe soch einfach mal statt des Classpath bzw. der cp-Variable nur den Pfad zur Anwendung und rufe sie dann mit java.exe auf.
also etwa so:

set path=.;C:\Pfad_zur_JRE;C:\Programm-Pfad
java MainClass

Geht das?

 

[Bleiglanz]

Ehrlich gesagt blick ich bei dir überhaupt nicht durch

C:\Programme\foobarz\jdk1.5\bin\java

 -cp loader.jar;service.jar;jta20.jar;resource.jar;shared.jar;gui.jar loader/SafeService

rufst du auf der Console das Java.exe aus der 1.5er DIREKT auf, bist du dir sicher dass in dieser Console kein JAVA_HOME, JRE_HOME CLASSPATH oder sonstiger Borlandischer Zeugs die 1.5er durcheinander bringt

Wenn, dann musst du schon eine "reine Console" aufbauen, in der alle Umgebungsvariablen "richtig gesetzt" sind und dann die java.exe aufrufen...

Übrigens würde ich noch den . in den Classpath reintun...

 

[thE_29]

Ihr versteht mich einfach net....

Ich habe 5 JDK/JREs auf meinem System mit verschiedensten Versionsnummern (glaub 2 1.5er und 3 1.4er)

Jedenfalls ist meine Standard JDK, die 1.4.2_04-b05

Und wenn ich mit einer anderen Testen will, ist es klar, das ich die dann mit einem Pfad angeben muss, ergo C:\Programme\java\jdk15\bin\java

das er mir auch mal eine andere Version nimmt!

Und es hat sicherlich nix mit dem zum tun, da mein Kollege mit einer höheren 1.4 Version (1.4.2_06-b03) hat und das Programm gar nicht starten geht.

Und ich habe genug Erfahrungen gesammelt, dass die viele Dinge ändern bei so einem kleinen Update.

(Unter Linux isses halt extremst! Mein Problem mit den kyrillischen Zeichen hat vielleicht jemand mitbekommen?? Das trat nur in der 1.4.2 auf, in der 1.4.1 war das Problem net da?? => ein Problem entsteht bei einem Update?? Noch ganz da SUN?? => eher nicht)


Achja nochwas, ich habe weder JAVA_HOME noch JRE_HOME gesetzt, da das komplett unnötige Variablen sind... (genau so wie classpath)

 

[thE_29]

Nachtrag³: http://www.hausmannstaetten.at/temp/safepay.zip

Jemand der Java 5 hat, soll das mal für mich testen und mir sagen ob es bei ihm geht!

Die bat Datei sollte stimmen, die sh weiß ich net!

 

[Bleiglanz]

java

-cp loader.jar;service.jar;jta20.jar;resource.jar;shared.jar;gui.jar loader/SafeService

kann doch gar nicht gehen, es fehlt das -jar argument

bist du zufällig in einem Ordner, in dem es einen Unterordner namens loader gibt?

und er dann rein Zufällig die SafeService.class aus diesem Unterordner nimmt?

und die loader.jar nur zur deko da ist?


und die Linux Datei ist kaputt, da ist ja der Classpath total daneben (es ist nur die loader.jar dabei) => dann kommt die gleiche Fehlermeldung wie bei dir

 

[thE_29]

Ähm, du kannst eine jar Datei auf 2 Arten starten!

Entweder

java -jar loader.jar

oder java -cp loader.jar loader/SafeService

Wenn im loader.jar keine main class angegeben ist, geht das 1. sowieso net, das 2te hingegen schon!

PS.: Die Linux datei habe ich mir nie angesehen, hab nur alles zusammengezippt!

 

[Bleiglanz]

oops, sorry

aber vielleicht liegts am jar??

Error! CRCs do not match! Got 1a824704, expected 79aca21a

kann ich irgendwie mit jar nicht auspacken?

 

[Guest]

Klassen mit Paketnamen werden nicht mit Slash (/) sondern mit Punkt angeben. D.h. (a) solltest du "loader.SafeService" statt "loader/SafeService" angeben und (b) in deiner Anwendung das auch bei Class.forName() etc so machen: gui.Gui und service.Service.

 

[thE_29]

Ich schätz mal an dem wirds liegen!

Ich hatte nämlich dieses / und . Problem schon mal woanders!

Leider ist diese Software net von uns, und daher kann ich den Zugriff drinnen mit Class.forName net ändern...


Ist aber schon komisch, das die alten Versionen das gekonnt haben und die neuen nicht mehr..