A newer version of Java is needed to view the application.

[BlackC]

Hallo Community,

ich hab ein Problem. Auf meinem Rechner ist das jdk 1.6.0_27 installiert. Jetzt kommt im meinem Browser(Firefox 8 ), wenn ich mein Applet(JavaFX) starte, die Meldung:

"A newer version of Java is needed to view the application. Click to update Java"

Ein update auf 1.6.0_29 ist nicht möglich, da mit dieser Version ich Probleme bekomme, eine Datenbankverbindung zu MS SQL Server 2008 aufzubauen.

Jetzt meine primäre Frage. Kann ich die Meldung umgehen, somit das Applet mit meiner aktuellen Javaversion läuft ?

Mfg BlackC

 

[Final_Striker]

Bist du dir sicher, dass das Applet kein Java 7 braucht?

edit: ah, hab überlesen, dass es dein Applet ist...

 

[BlackC]

das Problem ist eben, dass ich selbst mit der Java7u1-Version keine Verbindung mit dem MS SQL-Server bekomme. Ich hoffe zwar, dass es sobald wie möglich seitens Oracle bzw. von MS mit neuem Treiber gelöst wird ...

 

[Michael...]

Nur weil auf Deinem Rechner ein JDK 1.6 drauf ist heisst das noch lange nicht, dass der Browser auch ein 1.6 JRE benutzt. Schau einfach mal unter den Browsereinstellungen welche JRE für Applets verwendet wird.
Ansonsten könnte man ja auch unter Java 1.5 kompilieren. Wenn im Code keine Java 1.6 spezifischen Elemente enthalten sind.

 

[irgendjemand]

also auf anhieb würde mir hier nur einfallen das das applet mit Java7 compiled wurde ... da es unter sub-versionen keine sprachlichen änderungen gibt *ja klar ... immer mal wieder bug-fixes und so ... aber rein sprachlich ändert sich nichts* ...

wesshalb du unter der aktuellen version von java *egal ob 6u29 oder 7u1* probleme hast eine datenbank anzusprechen obwohl dies mit 6u27 geht kann ich mir nicht erklären da die unterschiede zwischen 6u27 und 6u29 kaum bemerkbar sein sollten ...
die unterschiede zu java7 sind schon größer ... jedoch größtenteils auch nur spracherweiterungen ... und keine veränderungen ...

bei firefox gibt es eine adresse die sich "aboutlugins" nennt ... damit kann man sehr gut sehen welche plugins in welchen versionen in FF installiert sind

 

[BlackC]

@ irgendjemand

Da das applet von mir ist und ich nur mit dem jdk 1.6.0_27 arbeite, ist es nicht mit 7 erstellt.

Das der Bug bekannt ist, steht auch in der BugDB von Oracle. (Bug ID: 7103886 6.0 u27 upgraded to u29: JDBC for SQLServer hangs on connect )

Ich werd mal ein extra Topic für diesen Bug aufmachen, eventuell hat ja jemand eine Lösung dafür ...

BTTen Update-Zwang kann man also nicht so einfach umgehen ?

 

[Michael...]

BTTen Update-Zwang kann man also nicht so einfach umgehen ?

Welchen Update Zwang? Wenn die Applikation mit 1.6 kompiliert wurde brauch man nunmal eine JRE der Version 1.6, da ja von Version zu Version sprachliche Erweiterungen dazu kommen. Wenn diese nicht verwendet werden kann man ja auch mit 1.5 komplilieren, oder wenn man mag mit einer noch niedrigeren Version.
Welche JRE verwendet denn jetzt der Browser?

 

[BlackC]

Oh, sry, hatte ich vergessen.

Als einziges Plugin, was mit Java zu tun hat, ist das "Java Deployment Toolkit 7.0.0.147"

Das würde erklären, dass er kein 1.6 findet. Nur hab ich jetzt sicherheitshalber das jdk (1.6.27) installiert, hat mir aber kein plugin zusätzlich installiert. Wenn ich dass 1.6.29 installiere, funktioniert die Installation und ein plugin ist drin. Nur die funktioniert ja nicht ...

 

[irgendjemand]

ich hab mir den bug mal bei sun *oder oracle oder wer auch immer* durchgelesen und es war von der klassifizierung wenig überrascht

das problem scheint mit einer veränderung von SSL/TLS zwischen 6u27 und 6u29 zusammen zu hängen ...
angeblich wurde bereits ein fix in 6u30 ausgeliefert ... die es so aber noch nicht zum downloaden gibt ...
auch steht nichts von 7ux ... also wird dieser fehler vermutlich auch noch im 7u1 stecken und dementsprechend frühestens mit 7u2 für J7 gefixt

jedoch sind mir bereits weitere änderungen im java-crypto system aufgefallen ...
wenn man in J6 z.b. mit AES arbeitet kann man sich mit einer SecretKeyFactory einen AES-SecretKey generieren lassen ... in J7 und 7u1 fliegt aller dings eine fehlermeldung das es keinen provider für AES für SecretKeyFactory gibt ... obwohl laut 7u1 Doc AES als einer der standard-key-system für SecretKeyFactory vorgeschreiben ist ...

nach suche im bug-traker eine ernüchterne antwort von Sun : da man bereits aus einer SecretKeySpec einen gültigen AES-SecretKey bekommt OHNE dafür überhaupt eine SecretKeyFactory verwenden zu müssen wurde dies ganz still und heimlich in J7 entfernt ... ohne mal die Doc anzupassen oder mal irgendwo einen hinweis zu geben ...

aufgefallen ist mir das als ich einen alten unter J6 geschriebenen code der unter J6 auch läuft in J7 ausführen wollte und dann halt über diese unsuported-algo-exception gestolpert bin ...


naja back 2 topic

ich würde hier aber ganz erlich Microsoft die schuld zu schieben *mach ich sowieso* weil sich die dort verantwortlichen zu sehr darauf verlassen haben das die von java genutzten lib's nicht geändert werden ... genau das ist aber passiert ... und M$ hat darauf nicht reagiert ...
ich meine ... wo wäre das problem für M$ gewesen einfach mal eine entsprechende crypto-impl dem driver beizulegen um unabhängig von Java zu sein ... aber wir kennen ja alle die arbeitsweise dieser stümper

 

[bronks]

... wo wäre das problem für M$ gewesen einfach mal eine entsprechende crypto-impl dem driver beizulegen um unabhängig von Java zu sein ... aber wir kennen ja alle die arbeitsweise dieser stümper

Was soll man denn bitte noch alles in den Driver und externe Libs rein packen? Jetzt auch noch vorsorglich!

 

[irgendjemand]

nun ja .. wir wissen alle das M$ entweder nur klaut *und dann sogar ziemlich schlecht* oder sich selbst was ausdenkt und das dann unter verschluss hält ...
wer bitte soll denn die möglichkeit haben sowas zu testen ?
wenn M$ sich darauf verlässt das ein produkt auch zukünftig läuft ... dann sollte es den entwicklern der zielplattform dafür auch mal die spezifikationen geben damit diese das testen können ...

hätte Sun z.B. einblicke in die arbeitsweise des M$ drivers und wären speziell angewiesen wurden : prüft das mal ... dann hätte Sun gleich sagen können : sorry leute ... so nicht ... und auch die fehler aufzeigen können ...

jetzt ärgern sich wieder 1mio user darüber das mal wieder was von M$ nicht geht ...

hätte man aber vermeiden können in dem man bei M$ alles in java programmiert hätte ... was zwar auf kosten von cpu-leistung und runtime geht ... aber so hätte M$ wenigstens volle kontrolle über alles gehabt ... und müsste sich jetzt nicht mit änderungen in der crypto-lib von java rumschlagen ...

 

[bronks]

... hätte man aber vermeiden können in dem man bei M$ alles in java programmiert hätte ...

Das ist ja echt interessant! Welche Teile des JDBC4-Treibers hat MS nicht mit Java programmiert und v.a. mit was hat es MS gemacht?

 

[irgendjemand]

wenn du dir mal den bug-tracker durchgelesen hättest wüsstest du das das problem des MS-SQL-drivers mit änderungen der crypto-lib zu tun hat ... welche dem anschein nach offensichtlich nicht von M$ programmiert wurden ... sonst würde sich der fehler ja nicht auf diese änderung zurückverfolgen lassen ...

und genau diesen teil meine ich ...

wenn M$ schon so erpicht drauf ist eine verschlüsselte verbindung aufzubauen ... warum haben sie das dann nicht angepasst an ihren driver und dem sql-server selbst implementiert ?
alternativ könnte man sicher noch was mit bouncy-castle versuchen ...

 

[bronks]

wenn du dir mal den bug-tracker durchgelesen hättest wüsstest du das das problem des MS-SQL-drivers mit änderungen der crypto-lib zu tun hat ... welche dem anschein nach offensichtlich nicht von M$ programmiert wurden ... sonst würde sich der fehler ja nicht auf diese änderung zurückverfolgen lassen ...

Hättest Du bitte einen Link für mich.

 

[bronks]

Ich habs schon gefunden.

Es funktioniert ja nicht einmal mit dem vielbeweihräucherten jTDS. Einem OpenSourceProjekt in welches jeder reinschaun kann. Echt peinlich für die JavaFrickler, welche wieder einen Teil der Abwärtskompatibilität ruiniert haben.

 

[age]

Auch OpenSource-Entwickler sind keine Götter, die überall immer alles sehen und überall gleichzeitig agieren können

 

[irgendjemand]

@bronks

siehe bitte post #6 *von TO* ... und klicke dich dann durch die "related bugs" bis uzm main-thread ... dort steht gleich ganz oben : java-crypto-error ...

und das der fehler mit einem einem anderen provider ebenfalls auftritt zeitg das der fehler bei java liegt und leider auch die entwickler dieses anderen providers den selben fehler wie M$ begangen haben ...


was abwärtskompatibilität angeht ...
meine persönliche meinung : wenn sich JEDER ... und damit meine ich wirklich JEDER ... an neue versionen halten würde ... und damit meine ich auch die ENTWICKLER ... die ihre codes dann auch auf den neuen versionen testen SOLLTEN ... gäbe es keinen grund ... und dieses wort würde nicht mal existieren ... da aber hier gerade das größte problem liegt ... das es zwar neue versionen der plattform gibt ... aber sich niemand drum kümmert diese neuen versionen zu verwenden und vorhandene frameworks darauf zu testen ... gerät das ganze immer weiter aus ein ander bis irgendwann von Oracle selbst entwickeltes zeug auf grund von abwärtskompatibilität auf den neuen versionen nicht mehr laufen wird *ich hoffe das es nicht dazu kommen wird*

alles fing schon damit an als man mit J5.0 generics eingeführt hat ... allerdings auch gleichzeitig um kompatibilität mit alten versionen zu behalten die compiler so umgebaut hat das diese das ach so tolle TYPE-EREASURE ausführen ... was totaler schwachsinn ist da man J5.0 klasse eh nicht auf älteren VMs ausführen kann *zumindest nicht ohne mit nem hex-editor die class-version-number zu "hacken" ...

*tut man dies laufen allerdings erstaunlicherweis die meisten J7 klassen mit J7 spezifischem inhalt sogar unter J5.0 und einiges sogar unter J1.4.x ...*

 

[BlackC]

also wie schon in meinem anderen Thread geschrieben und es hier ja auch erwähnt wird, liegt der Fehler an der Verschlüsselung. Hab diese nun ausgemacht und bin auf jTDS umgestiegen.

Ich hoffe einfach mal, dass mit dem SQL-Server 2012 ein neuer Treiber für jdbc gibt, der diesen Bug dann auch beseitigt.