# Prüfen welche JRE-Version gebraucht wird



## Guest (31. Aug 2007)

Hallo,
gibt es einen schnellen Weg zu überprüfen, welche JRE-Version benötigt wird um das Programm zu auszuführen?


----------



## T0M (31. Aug 2007)

Was mir dazu einfällt sind die Optionen des Java Compilers "source" und "target". Über target kannst du angeben, für welche (Mindest-)Version der Quellcode kompiliert werden soll. Gibt natürlich Einschränkungen, d.h. du kannst soweit ich weiß keinen Java 6 Sourcecode für eine JRE der Version 1.3 kompilieren (außer mit Zusatzprogrammen?).


----------



## merlin2 (31. Aug 2007)

Und das ist ein schneller Weg?


----------



## sparrow (31. Aug 2007)

Hallo Gast

möchtest du das aus einem Java Programm heraus feststellen oder allgemein?
Möchtest du also eine Klasse nachladen (z. B. aus einer Bibliothek) und vorher prüfen ob deine Java version ausreicht, oder hast du ein Java Programm und möchtest schauen welche JVM man dafür brauch?


Gruß
Sparrow


----------



## Guest (31. Aug 2007)

> oder hast du ein Java Programm und möchtest schauen welche JVM man dafür brauch?



Genau das will ich :wink: 

@T0M: Das ist glaube ich nicht das was ich suche.


----------



## Guest (1. Sep 2007)

Keiner eine Idee?


----------



## semi (2. Sep 2007)

Anonymous hat gesagt.:
			
		

> Keiner eine Idee?


Du kannst die Version der Class-Dateien auslesen.
Siehe: http://en.wikipedia.org/wiki/Class_(file_format)


----------



## Guest (2. Sep 2007)

Irgendwie verstehe ich nicht was der Artikel mir sagen will, bzw. wie mir das helfen soll  :cry:


----------



## byte (3. Sep 2007)

Anonymous hat gesagt.:
			
		

> > oder hast du ein Java Programm und möchtest schauen welche JVM man dafür brauch?
> 
> 
> 
> Genau das will ich :wink:



Die aktuellste. :roll:


----------



## Saxony (3. Sep 2007)

Hiho,

oder:

JRE 1.1 installieren - schauen ob es läuft - wenn nicht uninstall 1.1 install 1.2 usw. bis zur 1.6.
Dann findest du auch die Mindestversion. 

bye Saxony


----------



## bronks (4. Sep 2007)

byto hat gesagt.:
			
		

> ... Die aktuellste. :roll:


Da brauchst garnicht so die Augen zu verdrehen.   So großartig abwärtskompatibel ist Java auch wieder nicht und die Programme sollten günstiger weise mit der Javaversion ausgeführt werden mit der sie kompiliert wurden. 

Javaprogramme verhalten sich gerne und oft auf jedem Betriebssystem anders und das auch wieder in Abhängikeit davon auf welchem BS kompiliert wurde. Höchste Vorsicht ist leider immer geboten. 

Grosse bis unlösbare Probleme durch die Verwendung von neueren VM gibt es genug. Viele sehr bedeutende Programme laufen immernoch auf Java1.3.1, da es einfach zu viel Kosten würde diese umzubauen, aber auf der anderen Seite laufen die Programme nicht zuverlässig mit JVM > 1.3.1.


----------



## byte (4. Sep 2007)

Welche bedeutenden Programme wären das?

Kenne bisher nur Probleme, ältere Programme mit einer neuen Java-Version zu kompilieren, nicht aber ein älteres Kompilat mit einer neuen JRE auszuführen. Bestes Beispiel ist das derzeitige Projekt, in dem ich tätig bin. Kompiliert mit 1.4 läuft es problemlos mit JRE 5 oder 6.


----------



## bronks (4. Sep 2007)

byto hat gesagt.:
			
		

> Welche bedeutenden Programme wären das? ...


Es ist nichts öffentlich zugängliches bzw. käufliches. 



			
				byto hat gesagt.:
			
		

> ... Kenne bisher nur Probleme, ältere Programme mit einer neuen Java-Version zu kompilieren, nicht aber ein älteres Kompilat mit einer neuen JRE auszuführen. Bestes Beispiel ist das derzeitige Projekt, in dem ich tätig bin. Kompiliert mit 1.4 läuft es problemlos mit JRE 5 oder 6.


Von 1.4 aufwärts sind mir bis jetzt keine vergleichbare Probleme untergekommen. Davor wurden bei jeder Javaversion vorhandene Sachen so verbogen, daß es nicht mehr lustig war. Das für die Kompatibilität größte Desaster ist die Version von Swing, die ab Java1.4 dabei ist. Da passieren mit alten Programmen offensichtliche Fehler, die ein Programm teilweise unbrauchbar machen und auch in der Lage sind vorhandene Daten zu vernichten, wenn man die Programme mit  einer neueren JVM einsetzt.


----------



## tuxedo (4. Sep 2007)

Also ich kenn da bis dato nur eines:

Das ist eine Anwendung für Reisebüros. Damit werden Flüge bei den Fluglinien gebucht. Nennt sich "Amadeus". 

Aus einem mir unerklärlichen Grund läuft das Programm nicht mehr richtig wenn ein JRE über 1.4.2 Update 10 installiert ist. 

Warum? Kein Plan. Das weiß glaub ich keiner so genau (nichtmal der Amadeus Support). Fazit: Hat man noch andere Java.-Programme, die z.B. 1.5 brauchen, dann kommt man bei Amadeus um zwei JRE Installationen nicht drum rum. 

Würde mich mal interessieren was die Gründe für die mangelnde Kompatibilität sind? (Außer vielleicht der Verwendung von längst überfalligen "deprecated" Methoden).

- Alex


----------



## Saxony (4. Sep 2007)

alex0801 hat gesagt.:
			
		

> Würde mich mal interessieren was die Gründe für die mangelnde Kompatibilität sind? (Außer vielleicht der Verwendung von längst überfalligen "deprecated" Methoden).



Meine Theorie hierzu:

Wenn eine Methode in irgendeiner Version deprecated wird, denken die Entwickler noch die nächsten 1-2 Versionen daran diese weiterhin mit zu unterstützen/mitzuschleifen.
Je länger das aber her ist, um so wahrscheinlicher wird es, dass Änderungen in den Tiefen von Java vorgenommen werden. Diese Änderungen beziehen sich dann aber auf die Ersatzmethoden zu den deprecated und nicht mehr auf die deprecated selber.
Verwendet aber nun eine Anwendung diese alten deprecated Methoden und zeitgleich eine neue JRE, kann es zu Fehlern kommen.

bye Saxony


----------



## byte (4. Sep 2007)

bronks hat gesagt.:
			
		

> Von 1.4 aufwärts sind mir bis jetzt keine vergleichbare Probleme untergekommen. Davor wurden bei jeder Javaversion vorhandene Sachen so verbogen, daß es nicht mehr lustig war. Das für die Kompatibilität größte Desaster ist die Version von Swing, die ab Java1.4 dabei ist. Da passieren mit alten Programmen offensichtliche Fehler, die ein Programm teilweise unbrauchbar machen und auch in der Lage sind vorhandene Daten zu vernichten, wenn man die Programme mit  einer neueren JVM einsetzt.


Das ist richtig, betrifft aber doch eher einen kleinen Teil Anwendungen, die älter als 2002 und heute noch im Einsatz sind (kenne persönlich wenige bis gar keine).


----------



## tuxedo (4. Sep 2007)

Wenn ich deine Fassung mal kürzen darf:

deprecated methoden sind irgendwann so verbuggt (bedingt durch die Änderungen in den Java-Eingeweiden), dass das Programm nicht mehr funktioniert.

Aus meiner Sicht der Dinge: Das ist Quick'n'Dirty und zeugt von keiner guten Qualität... Und Geld machen die auch noch damit. *unverschämt*

Ander sieht es aus, wenn ein Programm für eine aktuelle Version geschrieben wurde, und das Programm, 3 JRE Generationen später immer noch eingesetzt wird. Damals, zur Zeit der Entwicklung waren die Methoden noch gar nicht deprecated, und 3 Generationen später sind sie es, und das sogar schon endgültig. 

In beiden Fällen kann Java nix dafür dass keine echte abwärtskompatibilität besteht... Schließlich waren die Änderungen ja lange angekündigt.


Tja. Das läuft ja wieder auf den selben Fakt hinaus: Entwickler sind zu Faul sich auf neue Methoden einzustellen, und verwenden, mal angenommen sie benutzen ein aktuelles JDK, jetzt schon alte Methoden die dann in der kommenden JRE/JDK nicht mehr funktionieren. 
Und das würde bronks Argument entkräften. 

Oder gibts noch nen Grund warum ein "altes Programm" nicht mit einer "neuen" JRE läuft (von deprecated methoden mal abgesehen).

- Alex


----------



## bronks (4. Sep 2007)

Dass die Entwickler faul sind kann man so nicht stehen lassen. Eher ist es dem Auftraggeber nicht das Geld wert, entsprechende Änderungen durchzuführen. So habe ich hier ein Projekt welches 1999 begonnen wurde mit > 500000 LOC, welches ausschließlich für Java1.3.1 freigegeben ist. Erstens läßt es sich nur mit 1.3 kompilieren, zweitens macht das mit 1.3 kompilierte auf >1.4 Probleme und drittens verwendet es Libs, die nicht mehr weiterentwickelt wurden. Prognostizierter Aufwand, um es auf eine neue Javaversion zu bringen liegt bei +-1250 Manntagen, wobei altlasten abgeschüttelt werden könnten. Niemand ist bereit soviel Geld auszugeben. Da installiert man doch lieber eine zweite JRE.

Und jetzt lasse ich meiner bösen Zunge freien Lauf: Mit .NET von Microsoft gibt es diese Probleme nicht, denn ein Programm welches für 1.1 gemacht ist verlangt nach der 1.1 und läuft nicht auf 2.0.


----------



## tuxedo (4. Sep 2007)

Naja, ein 8 Jahre altes Programm.. Da hat das wirklich nix mit faul zu tun. Das ist einfach der lauf der Zeit. 1.3.x ist halt einfach schon mehrfach überholt. Das auf den neusten Stand zu biegen ist klar aufwendig.

Das was ich gemeint habe ist, dass es "Faul" wäre, wenn ihr damals schon, 1999 mit Java 1.3.1 deprecated Methoden benutzt hättet...
DAS wäre Faul.

Und genau diese Faulheit scheinen heute noch manche Firmen zu praktizieren. 

Dass M$ nicht für die beste Kompatibilität steht wissen wir ja. Erst letzt hat mein Dad seinen 2,5 Jahre alten Drucker entsorgt weil Windows Vista den Treiber nicht mehr mochte und der Hersteller es sich wohl nicht leisten wollte Microsoft hinterher zu entwickeln. 
Ein Generationensprung und schon ist man raus.
Bei Java dauerts zum Glück meist länger wie nur einen einzigen Versionssprung bis deprecated Methoden rausfallen.

- Alex


----------



## Guest (4. Sep 2007)

Anonymous hat gesagt.:
			
		

> Irgendwie verstehe ich nicht was der Artikel mir sagen will, bzw. wie mir das helfen soll  :cry:


Du liest einfach die Klasse mit der main-Methode aus der Jar-Datei oder woher auch immer und prüfst die Version im Header der Datei. Anhand der Version kannst du ermitteln, welches JRE benötigt wird.


----------

