Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Am 19.03.2015 um 20:11 schrieb Michael Hagedorn: >> java -cp . Schwingung > > Es bleibt dabei ... > ./java -cp . Schwingung > Exception in thread "main" java.lang.ClassFormatError: Invalid start_pc Update: Ein Applet kann nur im Browser oder mit dem Appletviewer (im JDK) gestartet werden. ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hi. "Schön", dass hier alle das gleiche Problem haben ... da fühlt man sich doch gleich in bester Gesellschaft :) > Walter Fendt und auch Youtube stellen ja bereits auf HTML5 um, damit man > Java und Flash mit deren Sicherheitsproblemen nicht mehr benötigt. Ja, aber auch da gilt: Der ist noch LANGE nicht fertig damit ... es gibt halt noch tonnenweise Zeug, das nicht mehr umgestellt wird (z.T. auch, weil sich niemand mehr daraum kümmert). Ein bedauernswertes Beispiel ist die Seite "Physik 2000", die die Uni-Bonn vor ein paar Jahre herausgebracht/übersetzt hat. Die Texte waren wirklich super und die Animationen / Java-Applets waren gut und aussagekräftig. Plötzlich ist die Seite verschwunden und existiert jetzt nur noch im amerikanischen Original. Auch da war es ein Java-Problem, wenn ich mich richtig erinnere... > Das darf man in Windows 7 nur, wenn man "Computeradministrator" ist. Das Notebook im Ph-Fachraum startet von selbst durch (ohne Anmeldung) damit es morgens schneller geht. Das funktioniert auch halbwegs, weil die Kollegen in der Physik zum Großteil wissen, was sie da tun. Und normalerweise würde ich selbst ja auch jedes Java-Update anstoßen. Dass es dieses Mal (wieder) zu solch ungeahnten Schwierigkeiten kommt, konnte ja keiner ahnen... > Wie startest Du das Applet lokal? Konsole ... s. anderer Beitrag. > mich darauf hin, dass man noch mehr Dateien von der Website benötigen > könnte. Im Quelltext wird aber nur diese eine Class-Datei eingebunden ... ob die selbstständig noch etwas anderes nachladen will, weiß ich nicht. Doch ich hatte dieses spezielle Applet bereits offline laufen; von daher gehe ich davon aus, dass es so gehen müsste. Michael ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Am 19.03.2015 um 20:11 schrieb Michael Hagedorn: >> java -cp . Schwingung > > Es bleibt dabei ... > ./java -cp . Schwingung wenn Du mir mal den DL-Link gäben tätest... oder die .class schicken ... ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
> java -cp . Schwingung Es bleibt dabei ... ./java -cp . Schwingung Exception in thread "main" java.lang.ClassFormatError: Invalid start_pc 457 in LocalVariableTable in class file Schwingung at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$100(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source) Wobei: ~/temp/jre1.7.0_45/bin$ ./java -version java version "1.7.0_45" Java(TM) SE Runtime Environment (build 1.7.0_45-b18) Java HotSpot(TM) Server VM (build 24.45-b08, mixed mode) Ich würde ja ein Ersatz-Applet wählen -- doch dieses kann Dinge einblenden, die ich bei allen anderen, die ich kenne, bisher vermisse (z.b. dyn. Kräftezerlegung, gleichzeitige Anzeige einer harm. Schwingung usw...) ... mit anderen Worten: Es ist ziemlich simpel gehalten aber ist genial. Eine Alternative wäre: http://phet.colorado.edu/en/simulation/pendulum-lab -- das finde ich aber nicht so gut wie das Java-Applet :( Michael ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, ich spiele gerade Dein Szenario auf Windows 7 Prof. 64-bit mit Java 8u40 durch. Weiteres in Deinem Text ... Alles in allem würde ich aber lieber auf Java-Applets verzichten, die nicht mehr mit der aktuellen Java-Version laufen, anstatt mich mit veralteter Middleware herumzuägern. Walter Fendt und auch Youtube stellen ja bereits auf HTML5 um, damit man Java und Flash mit deren Sicherheitsproblemen nicht mehr benötigt. Genau so habe ich mich gerade gegen eine lokale Installation von Scatch 2.0 entschieden, weil ich hierfür ein veraltetes Adobe Air in Linux installieren müsste. Für den Acrobat Reader ließ sich dies wegen behördlicher Abrechnungsformulare leider nicht vermeiden. Für Flash wegen YouTube vorerst auch nicht - aber da besteht ja Hoffnung auf Besserung. Die baden halt mit viel Geld genüßlich in ihrer kommerziellen Softwarewelt :-( Auf Java baut unser Informatik-Unterricht in weiten Teilen auf. Auf das BrowserPlugIn könnten wir notfalls verzichten, wenn es zu gefährlich wird. Vielleicht muss man diese Sicherheitsfragen in einer Schule mit linbo im Rücken auch nicht ganz so verbissen sehen wie in einem Unternehmen oder auf dem persönlichen Rechner. Die KollegInnen wissen, dass sie die Schulrechner nicht für Geschäftliches nutzen dürfen und Time for Kids blockiert die meisten Adressen auch. Gruß Jürgen Am 19.03.2015 um 06:12 schrieb Michael Hagedorn: >> wo lief es nicht? Win oder Linux? > Dieses mal zu Hause -- Linux. > > Es soll aber eigentlich in der Schule laufen (Fachraum mit Win7-NB). > Dort läuft es aber momentan auch nicht; ich fürchte, dass da jemand das > Java-Upgrade auf V8 ebenfalls durchgeführt hat :( Das darf man in Windows 7 nur, wenn man "Computeradministrator" ist. Ist dies in Deiner Schule etwa jemand außer Dir, der so etwas macht, ohne darüber mit Dir zu sprechen?! > > Zum Vorgehen: Ich habe die Datei "Schwingung.class" des Applets > heruntergeladen und wollte es lokal starten... Wie startest Du das Applet lokal? Wenn ich es mit einer simplen HTML-Datei mache, bekomme ich dieselbe Fehlermeldung wie im WWW. Dabei ist es egal, ob ich Firefox oder den Internet Explorer als Browser verwende. Diese Datei habe ich in den Java Systemsteuerung als Ausnahme eingetragen. Ich finde keine weitere Stelle, wo das Ausführen noch freigeschaltet werden könnte. --- Beginn schwingung.htm --- --- Ende schwingung.htm --- Da ich im IE eine FM "wrong filename schwingung" erhielt, habe ich es mit dem großen S versucht und bekam dann anliegende FM. Das deutet für mich darauf hin, dass man noch mehr Dateien von der Website benötigen könnte. Jede FM gibt es übrigens nur nach dem ersten Aufruf, wenn man etwas verändert hat. Danach hat der Browser die Seite im Cache. > > Michael > > > ___ > linuxmuster-user mailing list > linuxmuster-user@lists.linuxmuster.net > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, Am 19.03.15 schrieb Michael Hagedorn : > Zum Vorgehen: Ich habe die Datei "Schwingung.class" des Applets > heruntergeladen und wollte es lokal starten... besteht das Applet nur aus Schwingung.class? Falls ja, könnte der Aufruf so funktionieren: java -cp . Schwingung Falls nicht, muss noch der Classpath (cp) erweitert werden: z.B.: set classpath=%classpath%;.;C:\Programme\Java\jre6_33\lib\rt.jar Dirk ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
> wo lief es nicht? Win oder Linux? Dieses mal zu Hause -- Linux. Es soll aber eigentlich in der Schule laufen (Fachraum mit Win7-NB). Dort läuft es aber momentan auch nicht; ich fürchte, dass da jemand das Java-Upgrade auf V8 ebenfalls durchgeführt hat :( Zum Vorgehen: Ich habe die Datei "Schwingung.class" des Applets heruntergeladen und wollte es lokal starten... Michael ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, Am 18.03.2015 um 21:27 schrieb Michael Hagedorn: > Lief allerdings auch nicht (was mich einigermaßen verwundert hat). Denn > so könnte man das Problem natürlich schön lösen, indem man lokal eine > alte Installation parat hält, die Firefox aber nicht kennt/benutzt. wo lief es nicht? Win oder Linux? Dirk ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Hans-Dietrich, HULC ist ein angepasstes Kubuntu 14.04 64-bit. Eine 32-bit-Version wird auch angeboten - in unserer Schule gibt es jedoch inzwischen keine 32-bit-Rechner mehr. Wenn Du ihn herunterlädst sind aus meiner Erinnerung heraus OpenJDK 6 und und Oracle 7 installiert, wobei das Oracle Java glaube ich der Standard ist. Bei uns habe ich beide entfernt und stattdessen OpenJDK 7 installiert. Rohners JavaEditor läuft bei uns in wine und benötigt dort die Windows-Version des Oracle JDK 7. Das Oracle JDK 8 ließ sich dort gar nicht installieren. Mag daran liegen, wie wine konfiguriert ist. Gruß Jürgen Am 18.03.2015 um 22:11 schrieb Hans-Dietrich Kirmse: > Hallo Michael, hallo Jürgen, > > Am 18.03.2015 um 21:58 schrieb Juergen Engeland: >> Hallo Michael, >> >> ich habe noch nicht probiert, ob das aktuelle Firefox für Windows es >> findet, aber als ich auch so wie von Dir beschrieben gedacht hatte, >> musste ich feststellen, dass Firefox die 64-bit-Version nicht fand. > > Genau das ist das Problem. Firefox ist das eine Programm und Java ein > anderes. Wenn Firefox eine Seite lädt mit einem Java-Applet, dann muss > es etwas geben, was zwischen Firefox und Java vermittelt und das ist > das Java-Plugin. Und genau dieses Plugin wurde/wird bei der > 64-Bit-Version von Java nicht installiert. Damit findet Firefox das > Java nicht. Ich vermute sehr, dass das nicht nur die Windows-Version > betrifft, und dann wäre die Fehlermeldung aus der Mail 21:27 zumindest > zu erklären (nur Vermutung). > >> Dies konnte ich damals auch im WWW verifizieren und seitdem habe ich nur >> noch die 32-bit-Version in meinem 64-bit-Windows. >> >> In der Schule hat sich das Thema dank HULC zum Glück vorerst erledigt >> ;-) > > @Jürgen: die Begründung verstehe ich nicht, denn bei Michal geht es um > Linux-Clients, zudem KUbuntu. Wenn ich mich recht erinnere setzt HULC > doch auch auf KUbuntu, oder irre ich mich da? > > Viele Grüße > Hans-Dietrich > ___ > linuxmuster-user mailing list > linuxmuster-user@lists.linuxmuster.net > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Am 18.03.2015 um 21:35 schrieb Michael Hagedorn: Wofür ist 64-bit-Java in Windows sinnvoll? Ich nehme mal stark an, dass der Gedankengang so geht: "Ich habe einen tolle CPU, die 64 bittig ist -- dann lade ich auch nur 64-Bit-Programme runter " Oder?? Bei mir ist es folgender Gedankengang gewesen: ein 64-bit -Betriebssystem hat ein entsprechendes Speichermodell, die Programm dazu natürlich auch, was natürlich dann passt. 32-bit-Betriebssysteme und Programme ein anderes. Wenn also jetzt in einer 64-bittigen Umgebung ein 32-Bit-Programm läuft, dann muss der 32-bit-speicherbereich in den 64-bittigen Speicherbereich eingebunden bzw. eingeblendet werden. Hier muss vermittelt oder nenne es halt "übersetzt" werden. ein weiteres Problem sind die übergebenen Daten. Dabei ist es noch ein leichtes, die Daten aus der 32-bit-umgebung nach der 64-bit-Umgebung zu reichen. Andersherum ist das schon etwas aufwendiger - geht aber. Allerdings sind diese Transformationen einfach völlig nutzlos. Wenn ich die Wahl habe, dann sollte das System aus einem Guss sein. Deswegen habe ich zuerst zu 64-Bit-Java gegriffen. Aber es ist eh uninteressant, das Kriterium ist, dass das 64-bit-Java unter Windows das benötigte Plugin nicht mitliefert. Deshalb ist alles oben Geschriebene einfach uninteressant (geworden). Viele Grüße Hans-Dietrich ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, hallo Jürgen, Am 18.03.2015 um 21:58 schrieb Juergen Engeland: Hallo Michael, ich habe noch nicht probiert, ob das aktuelle Firefox für Windows es findet, aber als ich auch so wie von Dir beschrieben gedacht hatte, musste ich feststellen, dass Firefox die 64-bit-Version nicht fand. Genau das ist das Problem. Firefox ist das eine Programm und Java ein anderes. Wenn Firefox eine Seite lädt mit einem Java-Applet, dann muss es etwas geben, was zwischen Firefox und Java vermittelt und das ist das Java-Plugin. Und genau dieses Plugin wurde/wird bei der 64-Bit-Version von Java nicht installiert. Damit findet Firefox das Java nicht. Ich vermute sehr, dass das nicht nur die Windows-Version betrifft, und dann wäre die Fehlermeldung aus der Mail 21:27 zumindest zu erklären (nur Vermutung). Dies konnte ich damals auch im WWW verifizieren und seitdem habe ich nur noch die 32-bit-Version in meinem 64-bit-Windows. In der Schule hat sich das Thema dank HULC zum Glück vorerst erledigt ;-) @Jürgen: die Begründung verstehe ich nicht, denn bei Michal geht es um Linux-Clients, zudem KUbuntu. Wenn ich mich recht erinnere setzt HULC doch auch auf KUbuntu, oder irre ich mich da? Viele Grüße Hans-Dietrich ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, ich habe noch nicht probiert, ob das aktuelle Firefox für Windows es findet, aber als ich auch so wie von Dir beschrieben gedacht hatte, musste ich feststellen, dass Firefox die 64-bit-Version nicht fand. Dies konnte ich damals auch im WWW verifizieren und seitdem habe ich nur noch die 32-bit-Version in meinem 64-bit-Windows. In der Schule hat sich das Thema dank HULC zum Glück vorerst erledigt ;-) Gruß Jürgen Am 18.03.2015 um 21:35 schrieb Michael Hagedorn: >> Wofür ist 64-bit-Java in Windows sinnvoll? > Ich nehme mal stark an, dass der Gedankengang so geht: > "Ich habe einen tolle CPU, die 64 bittig ist -- dann lade ich auch nur > 64-Bit-Programme runter " > Oder?? In der beliebtesten aller Betriebssystemwelten ist vieles noch 32-Bit oder 64-Bit-Beta. MS Office 2010 wurde mir im Herbst 2012 auch für Windows 7 64-Bit als 32-Bit-Software empfohlen. Würde ich nicht wieder kaufen ... Aber auch LibreOffice 4.4 ist dort noch 32-Bit und findet 64-Bit-Java nicht - womit LibreBase nicht läuft. Bislang sehe ich den einzigen Vorteil von 64-bit-Windows darin, dass es mehr als 3 GB RAM adressieren kann. Bei 64-bit-Linux stellten unsere Schüler eine signifikante Leistungssteigerung beim rendern mit blender fest, gegenüber 32-bit. Die betroffenen Rechner haben nuer 2 GB RAM. KDE statt MATE dürfte hierfür nicht die Ursache sein. Der proprietäre Nvidia-Treiber musste immer installiert sein, um die native Auflösung der LCDs zu erreichen. > > > > > ___ > linuxmuster-user mailing list > linuxmuster-user@lists.linuxmuster.net > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
> Wofür ist 64-bit-Java in Windows sinnvoll? Ich nehme mal stark an, dass der Gedankengang so geht: "Ich habe einen tolle CPU, die 64 bittig ist -- dann lade ich auch nur 64-Bit-Programme runter " Oder?? ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Hans-Dietrich, in Linux mache ich mir für Java bislang keine Gedanken, ob eine 32- oder 64-bit-Umgebung installiert werden muss - das regelt das System schon ... es sei denn, man muss irgendwelchen veralteten proprietären Schrott kommerzieller Anbieter installieren :-( In Windows habe ich bislang keinen Sinn darin gesehen, 64-bit-Java zu installieren, da fast alle Anwendungen, die darauf zugreifen, 32-bit-Java benötigen oder damit auskommen. Wofür ist 64-bit-Java in Windows sinnvoll? Gruß Jürgen Am 18.03.2015 um 19:41 schrieb Hans-Dietrich Kirmse: > Hallo Michael, > > Am 18.03.2015 um 06:06 schrieb Michael Hagedorn: >> >>> Also es ist kein Problem von Linux, sondern von Java 8. Alles was ich >>> geschrieben hatte galt nur für Java 7. :( >> >> das "beruhigt" mich -- löst aber natürlich nicht das Problem :) > > sieht zwar so aus, aber ... > > ich habe gestern noch mehrere Stunden erfolglos versucht, dieses > Problem bestmöglich in den Griff zu bekommen, was mir aber erst heute > gelang. Eigentlich bin ich nur über 2 Stolpersteine gestolpert, aber > wenn schon, dann richtig. Damit du nicht ebenso Zeit vergeuden musst, > will ich dir mein Vorgehen und die Probleme schildern. > > Also, mit Java 8 gehen die Applets nicht. Also zurück zu Java 7. > Anmerkung: Java 7 wird bis April 2015 noch supportet. Das steht auf > dieser Seite: > > https://www.java.com/de/download/help/java_revert.xml > > Dazu Java komplett runtergeschmissen. Hier ist die erste Falle. Ich > habe ja auch noch ein JDK installiert -> das musste auch weg. Also > _alle_ Versionen von Java wegräumen. Auf der gerade angegebenen Seite > ist unter Punkt 3 ein Link zur letzten Version von Java 7. Der führt > auf diese Seite: > > https://www.java.com/de/download/manual_java7.jsp > > Dort sind für Windows 3 Versionen angegeben. Und schon kommt die > nächste Falle. Ich habe ein 64-Bit-Windows und einen 64-Bit-Firefox, > also habe ich natürlich die 64-Bit-Version von Java runtergeladen und > installiert. Ging auch ohne Probleme, aber die Applets gingen nicht. > Die Meldung war, dass ich das Java-Plugin installieren sollte. Dazu > findest sich aber nichts im Netz, nur dass das sowieso mitinstalliert > wird, was es aber bei mir nicht gemacht hat. Also Java gelöscht und > neu installiert - mehrfach - leider immer umsonst. Heute in der Schule > wieder gegoogelt und da fand ich in einem Forum, dass man die > 32-Bit-Version nehmen muss. Also wieder Java gelöscht und die > 32-Bit-Version von Java installiert. Und jetzt gingen die Applets > wieder (praktisch ohne Probleme). > > Mir war leider entfallen, dass ich damals ganz bewußt die > 32-Bit-Version von Java installiert hatte, weil ich in Informatik mit > dem Java-Editor von Gerhard Röhner arbeite bzw. gearbeitet habe und > dort ausdrücklich darauf hingewiesen wurde, das es mit der > 64-Bit-Version Probleme geben wird. Dummerweise war das bei mir bei > diesen Versuchen nicht mehr auf meinem Schirm. > > Zusammengefasst: > - die Applets gehen mit der aktuellen Version von Java 7 (Update 75) > - diese Version wird noch bis April 2015 gepflegt :( > - unter Windows unbedingt die 32-Bit-Version verwenden > - unsignierte Applets in die Ausnahmeliste eintragen (die Seiten!). > > > Eine Lösung für Java 8 habe ich nicht, aber ich bleibe dran. Sollte ja > gehen, weil (angeblich) kompatibel. Falls ich da was erreiche, melde > ich mich dazu wieder. > > Viele Grüße > Hans-Dietrich > > PS: wie es mit Linux-Clients aussieht weiss ich nicht, würde mich aber > interessieren. > ___ > linuxmuster-user mailing list > linuxmuster-user@lists.linuxmuster.net > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo. > Eine Lösung für Java 8 habe ich nicht, aber ich bleibe dran. Sollte ja > gehen, weil (angeblich) kompatibel. Falls ich da was erreiche, melde ich > mich dazu wieder. Danke für deine ganze Mühe/Zeit ... ich habe es heute auf diesem Weg versucht: Alte Java-Version ohne den ganzen Signatur-Mist gewählt: http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html#sjre-7u45-oth-JPR Dort eine alte Version heruntergeladen (allerdings auch 64 Bit!!! -- Fehler???) und dann per Hand (bzw mit dem von Dirk vorgeschlagenen EXPORT/PATH-Befehl) tmp/jre.../bin/java Schwingung Lief allerdings auch nicht (was mich einigermaßen verwundert hat). Denn so könnte man das Problem natürlich schön lösen, indem man lokal eine alte Installation parat hält, die Firefox aber nicht kennt/benutzt. Wenn es schlicht und einfach ein Java-8-Bug ist, könnte das Problem ja evtl auch beim nächsten Release behoben sein!?? Michael ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, Am 18.03.2015 um 06:06 schrieb Michael Hagedorn: Also es ist kein Problem von Linux, sondern von Java 8. Alles was ich geschrieben hatte galt nur für Java 7. :( das "beruhigt" mich -- löst aber natürlich nicht das Problem :) sieht zwar so aus, aber ... ich habe gestern noch mehrere Stunden erfolglos versucht, dieses Problem bestmöglich in den Griff zu bekommen, was mir aber erst heute gelang. Eigentlich bin ich nur über 2 Stolpersteine gestolpert, aber wenn schon, dann richtig. Damit du nicht ebenso Zeit vergeuden musst, will ich dir mein Vorgehen und die Probleme schildern. Also, mit Java 8 gehen die Applets nicht. Also zurück zu Java 7. Anmerkung: Java 7 wird bis April 2015 noch supportet. Das steht auf dieser Seite: https://www.java.com/de/download/help/java_revert.xml Dazu Java komplett runtergeschmissen. Hier ist die erste Falle. Ich habe ja auch noch ein JDK installiert -> das musste auch weg. Also _alle_ Versionen von Java wegräumen. Auf der gerade angegebenen Seite ist unter Punkt 3 ein Link zur letzten Version von Java 7. Der führt auf diese Seite: https://www.java.com/de/download/manual_java7.jsp Dort sind für Windows 3 Versionen angegeben. Und schon kommt die nächste Falle. Ich habe ein 64-Bit-Windows und einen 64-Bit-Firefox, also habe ich natürlich die 64-Bit-Version von Java runtergeladen und installiert. Ging auch ohne Probleme, aber die Applets gingen nicht. Die Meldung war, dass ich das Java-Plugin installieren sollte. Dazu findest sich aber nichts im Netz, nur dass das sowieso mitinstalliert wird, was es aber bei mir nicht gemacht hat. Also Java gelöscht und neu installiert - mehrfach - leider immer umsonst. Heute in der Schule wieder gegoogelt und da fand ich in einem Forum, dass man die 32-Bit-Version nehmen muss. Also wieder Java gelöscht und die 32-Bit-Version von Java installiert. Und jetzt gingen die Applets wieder (praktisch ohne Probleme). Mir war leider entfallen, dass ich damals ganz bewußt die 32-Bit-Version von Java installiert hatte, weil ich in Informatik mit dem Java-Editor von Gerhard Röhner arbeite bzw. gearbeitet habe und dort ausdrücklich darauf hingewiesen wurde, das es mit der 64-Bit-Version Probleme geben wird. Dummerweise war das bei mir bei diesen Versuchen nicht mehr auf meinem Schirm. Zusammengefasst: - die Applets gehen mit der aktuellen Version von Java 7 (Update 75) - diese Version wird noch bis April 2015 gepflegt :( - unter Windows unbedingt die 32-Bit-Version verwenden - unsignierte Applets in die Ausnahmeliste eintragen (die Seiten!). Eine Lösung für Java 8 habe ich nicht, aber ich bleibe dran. Sollte ja gehen, weil (angeblich) kompatibel. Falls ich da was erreiche, melde ich mich dazu wieder. Viele Grüße Hans-Dietrich PS: wie es mit Linux-Clients aussieht weiss ich nicht, würde mich aber interessieren. ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
> Also es ist kein Problem von Linux, sondern von Java 8. Alles was ich > geschrieben hatte galt nur für Java 7. :( das "beruhigt" mich -- löst aber natürlich nicht das Problem :) Michael ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, ich habe mich an einer Stelle massiv geirrt. Meine letzte Aktualisierung ist zwar gerade einen Monat her, aber ich hatte noch Java 7, du hast schon Java 8. Also habe ich aktualisiert auf Java 8 und habe den gleichen Fehler. Ich habe auch nach dem Fehler gegoogelt, aber in der Java-Dokumentation steht nicht, dass sich hier etwas geändert hat (seit JDK 1). müßte damit eigentlich kompatibel sein. Also es ist kein Problem von Linux, sondern von Java 8. Alles was ich geschrieben hatte galt nur für Java 7. :( Viele Grüße Hans-Dietrich Am 17.03.2015 um 21:33 schrieb Michael Hagedorn: und für die, die Linux als Clients benutzen, habe ich meine interne Anleitung noch ins anwenderwiki kopiert: Unter Linux (wie gesagt -- hier Kubuntu 14.04.2 LTS mit java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) (von deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main ) Dürfte also up-to-date sein ... ?!? ... ich erhalte aber leider das Bild "Diesmal erlauben" -- "Erlauben und Entscheidung merken" erst gar nicht! Zudem habe ich auch die Sicherheitsstufe "Mittel" hier nicht mehr. Es gibt nur noch "Hoch" und "Sehr hoch". Ob ich "jcontrol" oder "javaws" öffne, ändert übrigens nichts ... es ist das GLEICHE Programm. Unter /usr/bin Symlinks auf: jcontrol -> /etc/alternatives/jcontrol javaws -> /etc/alternatives/javaws und dort ein Symlink auf javaws -> /usr/lib/jvm/java-8-oracle/jre/bin/javaws jcontrol -> /usr/lib/jvm/java-8-oracle/jre/bin/jcontrol Übrigens: Bei diesem Applet http://bksd.nw.lo-net2.de/mathepool/Prozent/prozent_index.htm gibt es ÜBERHAUPT keinen Stress -- das wird ausgeführt und läuft! Michael ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, vorerst kommen wir mit den wenigen Applets die wir benötigen, BlueJ, Greenfoot, GeoGebra ... wunderbar klar, wenn nur das aus den Ubuntu-Repos aktualisierte OpenJDK 7 installiert ist. Halt stopp, SweetHome 3D bringt sein eigenes Oracle JRE 6 Am 17.03.2015 um 21:39 schrieb Michael Hagedorn: >> Dein Beispiel-Applet läuft auf unserem HULC auch nicht, wenn ich es erlaube. > Ok -- ... und das nervt doch!?? Nix da mit "plattformübergreifend" -- > wenn man sich nicht darauf verlassen kann :( > > Vielleicht also doch eine Rückkehr auf Java VOR 7u51? > > ___ > linuxmuster-user mailing list > linuxmuster-user@lists.linuxmuster.net > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
> Dein Beispiel-Applet läuft auf unserem HULC auch nicht, wenn ich es erlaube. Ok -- ... und das nervt doch!?? Nix da mit "plattformübergreifend" -- wenn man sich nicht darauf verlassen kann :( Vielleicht also doch eine Rückkehr auf Java VOR 7u51? ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
> und für die, die Linux als Clients benutzen, habe ich meine interne > Anleitung noch ins anwenderwiki kopiert: Unter Linux (wie gesagt -- hier Kubuntu 14.04.2 LTS mit java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode) (von deb http://ppa.launchpad.net/webupd8team/java/ubuntu trusty main ) Dürfte also up-to-date sein ... ?!? ... ich erhalte aber leider das Bild "Diesmal erlauben" -- "Erlauben und Entscheidung merken" erst gar nicht! Zudem habe ich auch die Sicherheitsstufe "Mittel" hier nicht mehr. Es gibt nur noch "Hoch" und "Sehr hoch". Ob ich "jcontrol" oder "javaws" öffne, ändert übrigens nichts ... es ist das GLEICHE Programm. Unter /usr/bin Symlinks auf: jcontrol -> /etc/alternatives/jcontrol javaws -> /etc/alternatives/javaws und dort ein Symlink auf javaws -> /usr/lib/jvm/java-8-oracle/jre/bin/javaws jcontrol -> /usr/lib/jvm/java-8-oracle/jre/bin/jcontrol Übrigens: Bei diesem Applet http://bksd.nw.lo-net2.de/mathepool/Prozent/prozent_index.htm gibt es ÜBERHAUPT keinen Stress -- das wird ausgeführt und läuft! Michael -- Systemdaten: - virtualisiert mit Proxmox 2.3 - linuxmuster.net 6.0.46 - IPFire 2.15 - Linbo 2.1.10-0 - Ubuntu 14.04 Clients (trusty714-Vorlage) - leoclient1 mit WinXP im offline-Modus - Moodle 2.7 (extern mit LDAPS und openLML-Modul) ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Tobias, genau so habe ich das auch gemacht. Gruß Jürgen Am 17.03.2015 um 21:20 schrieb "T. Küchel": > Hallo Michael, hallo Hans-Dietrich, > > > und für die, die Linux als Clients benutzen, habe ich meine interne > Anleitung noch ins anwenderwiki kopiert: > > http://www.linuxmuster.net/wiki/anwenderwiki:linuxclient:javaexceptions > > Grüße, Tobias > > Am 17.03.2015 um 20:59 schrieb Hans-Dietrich Kirmse: > > Hallo Michael, > > > herzlichen Dank für deine schnelle Reaktion. > > > Am 17.03.2015 um 18:09 schrieb Michael Hagedorn: > >> Ok ... ich habe ein Bsp gefunden... .diese URL habe ich soeben in > >> die Aufnahmeliste gepackt und firefox/java sogar neu gestartet > >> --- es bleibt aber dabei, dass das Applet nicht geladen wird :( > > > bei mir schon (nachdem ich es in die Ausnahmeliste eingetragen > > habe) > > >> http://verein.ai.ch/gym/fachsch/physik/schwingung.htm#top > >> > >> Ich habe es allerdings schon benutzt ... daher _muss_ es an > >> aktuellen Java-Versionen liegen. > > > Ich habe bei meiner "Einrichtung" hier zu Hause ein aktuelles Java > > - dachte ich zumindest. Mein letztes Java-Update war am 15.02.2015 > > - für mich ist das aktuell genug. ;) Auf jeden Fall hat es sich > > ohne Probleme überreden lassen, diese(s) Seite/Applet anzuzeigen. > > > Ich habe jeden Schritt als Screenshot festgehalten und auf dieser > > Seite bereitgestellt. Auch die HTML-Seite und die class-Datei > > bereiteten kein Problem (auf der Seite ganz unten). > > > http://www.erasmus-reinhold-gymnasium.de/java/applet.html > > > Ich kann zwar auch nochmal aktualisieren, aber da wird sich m.E. > > trotzdem nichts an der Situation ändern. Allerdings ist der > > Unterschied: ich habe hier zu Hause Windows7. Aber das sollte doch > > auch unter Linux genauso gehen - hoffe ich doch. > > > >> Es ist (meiner Meinung nach) aber auch (unter Linux) nicht > >> elegant gelöst, dass man die Ausnahme nicht einfach durch > >> anklicken "Erlauben und merken" laufen lassen kann!? Das "java > >> control panel" starte ich per "javaws" ... und muss mich dann > >> umständlich durchklicken und die Ausnahme hinzufügen. Meiner > >> Meinung klappt es auch nicht, einfach eine komplette Domain wie > >> www.leifiphysik.de hinzuzufügen und zu hoffen, dass das Problem > >> damit behoben ist > > > Es muss die URL der _Seite_ sein. Und wenn das Applet nicht im > > gleichen Verzeichnis wie die Seite liegt, dann muss man sogar 2 > > Ausnahmen eintragen. Wäre sicherlich einfacher zu lösen gewesen, > > aber trotzdem: es ist (für jede Seite) nur einmal zu tun. Insofern > > sind alle anderen Lösungen im Vergleich dazu entweder > > sicherheitstechnisch kaum zu verantworten oder aus meiner Sicht > > deutlich aufwendiger. > > >> Ich bleibe dabei: Java war schon mal _DEUTLICH_ > >> anwenderfreundlicher. > > > alle Dienste waren deutlich anwenderfreundlicher, als man sich > > nicht um Zertifikate (sprich signieren) kümmern musste, egal ob es > > nun um http -> https oder imap -> imaps oder DNS -> DNSSEC ist. > > Sicherheit gibt es nunmal nicht frei Haus. Und wenn Applets sicher > > sein sollen, dann müssen die signiert sein. In wie weit das mit > > Zertifikaten vergleichbar ist, bin ich momentan überfragt. Es > > spielt aber in Bezug auf Sicherheit die gleiche Rolle. > > > Ich gebe dir völlig recht: wenn man auf Sicherheit verzichtet, das > > ist deutlich anwendungsfreundlicher. > > >> Einen Gefallen hat Oracle den Usern nicht getan --- auch wenn es > >> sicherheitstechnisch notwendig war. > > > Die Bewertung würde bei mir anders aussehen, aber das war ja nicht > > das Problem. Für mich sieht es eigentlich so aus, dass genau diese > > Lösung bei mir (unter Windows) funktioniert und bei dir (unter > > Kubuntu) nicht. Wie könnten wir das Problem weiter eingrenzen? Soll > > ich mal ein KUbuntu installieren? > > > viele Grüße Hans-Dietrich > > > ___ linuxmuster-user > > mailing list linuxmuster-user@lists.linuxmuster.net > > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > > ___ > linuxmuster-user mailing list > linuxmuster-user@lists.linuxmuster.net > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, Dein Beispiel-Applet läuft auf unserem HULC auch nicht, wenn ich es erlaube. Allerdings liefert es in Firefox einen Fehler, und in Konqueror "Applet wurde nicht initialisert". Das sagt Oracle zu unserem OPenJDK 7: "Sie haben die empfohlene Java-Version installiert (Version 7 Update 75)." Gruß Jürgen Am 17.03.2015 um 18:09 schrieb Michael Hagedorn: > Ok ... ich habe ein Bsp gefunden... .diese URL habe ich soeben in die > Aufnahmeliste gepackt und firefox/java sogar neu gestartet --- es bleibt > aber dabei, dass das Applet nicht geladen wird :( > > http://verein.ai.ch/gym/fachsch/physik/schwingung.htm#top > > Ich habe es allerdings schon benutzt ... daher _muss_ es an aktuellen > Java-Versionen liegen. > > Es ist (meiner Meinung nach) aber auch (unter Linux) nicht elegant > gelöst, dass man die Ausnahme nicht einfach durch anklicken "Erlauben > und merken" laufen lassen kann!? Das "java control panel" starte ich per > "javaws" ... und muss mich dann umständlich durchklicken und die > Ausnahme hinzufügen. Meiner Meinung klappt es auch nicht, einfach eine > komplette Domain wie www.leifiphysik.de hinzuzufügen und zu hoffen, dass > das Problem damit behoben ist > Ich bleibe dabei: Java war schon mal _DEUTLICH_ anwenderfreundlicher. > Einen Gefallen hat Oracle den Usern nicht getan --- auch wenn es > sicherheitstechnisch notwendig war. > > Michael > > ___ > linuxmuster-user mailing list > linuxmuster-user@lists.linuxmuster.net > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Michael, hallo Hans-Dietrich, und für die, die Linux als Clients benutzen, habe ich meine interne Anleitung noch ins anwenderwiki kopiert: http://www.linuxmuster.net/wiki/anwenderwiki:linuxclient:javaexceptions Grüße, Tobias Am 17.03.2015 um 20:59 schrieb Hans-Dietrich Kirmse: > Hallo Michael, > > herzlichen Dank für deine schnelle Reaktion. > > Am 17.03.2015 um 18:09 schrieb Michael Hagedorn: >> Ok ... ich habe ein Bsp gefunden... .diese URL habe ich soeben in >> die Aufnahmeliste gepackt und firefox/java sogar neu gestartet >> --- es bleibt aber dabei, dass das Applet nicht geladen wird :( > > bei mir schon (nachdem ich es in die Ausnahmeliste eingetragen > habe) > >> http://verein.ai.ch/gym/fachsch/physik/schwingung.htm#top >> >> Ich habe es allerdings schon benutzt ... daher _muss_ es an >> aktuellen Java-Versionen liegen. > > Ich habe bei meiner "Einrichtung" hier zu Hause ein aktuelles Java > - dachte ich zumindest. Mein letztes Java-Update war am 15.02.2015 > - für mich ist das aktuell genug. ;) Auf jeden Fall hat es sich > ohne Probleme überreden lassen, diese(s) Seite/Applet anzuzeigen. > > Ich habe jeden Schritt als Screenshot festgehalten und auf dieser > Seite bereitgestellt. Auch die HTML-Seite und die class-Datei > bereiteten kein Problem (auf der Seite ganz unten). > > http://www.erasmus-reinhold-gymnasium.de/java/applet.html > > Ich kann zwar auch nochmal aktualisieren, aber da wird sich m.E. > trotzdem nichts an der Situation ändern. Allerdings ist der > Unterschied: ich habe hier zu Hause Windows7. Aber das sollte doch > auch unter Linux genauso gehen - hoffe ich doch. > > >> Es ist (meiner Meinung nach) aber auch (unter Linux) nicht >> elegant gelöst, dass man die Ausnahme nicht einfach durch >> anklicken "Erlauben und merken" laufen lassen kann!? Das "java >> control panel" starte ich per "javaws" ... und muss mich dann >> umständlich durchklicken und die Ausnahme hinzufügen. Meiner >> Meinung klappt es auch nicht, einfach eine komplette Domain wie >> www.leifiphysik.de hinzuzufügen und zu hoffen, dass das Problem >> damit behoben ist > > Es muss die URL der _Seite_ sein. Und wenn das Applet nicht im > gleichen Verzeichnis wie die Seite liegt, dann muss man sogar 2 > Ausnahmen eintragen. Wäre sicherlich einfacher zu lösen gewesen, > aber trotzdem: es ist (für jede Seite) nur einmal zu tun. Insofern > sind alle anderen Lösungen im Vergleich dazu entweder > sicherheitstechnisch kaum zu verantworten oder aus meiner Sicht > deutlich aufwendiger. > >> Ich bleibe dabei: Java war schon mal _DEUTLICH_ >> anwenderfreundlicher. > > alle Dienste waren deutlich anwenderfreundlicher, als man sich > nicht um Zertifikate (sprich signieren) kümmern musste, egal ob es > nun um http -> https oder imap -> imaps oder DNS -> DNSSEC ist. > Sicherheit gibt es nunmal nicht frei Haus. Und wenn Applets sicher > sein sollen, dann müssen die signiert sein. In wie weit das mit > Zertifikaten vergleichbar ist, bin ich momentan überfragt. Es > spielt aber in Bezug auf Sicherheit die gleiche Rolle. > > Ich gebe dir völlig recht: wenn man auf Sicherheit verzichtet, das > ist deutlich anwendungsfreundlicher. > >> Einen Gefallen hat Oracle den Usern nicht getan --- auch wenn es >> sicherheitstechnisch notwendig war. > > Die Bewertung würde bei mir anders aussehen, aber das war ja nicht > das Problem. Für mich sieht es eigentlich so aus, dass genau diese > Lösung bei mir (unter Windows) funktioniert und bei dir (unter > Kubuntu) nicht. Wie könnten wir das Problem weiter eingrenzen? Soll > ich mal ein KUbuntu installieren? > > viele Grüße Hans-Dietrich > > ___ linuxmuster-user > mailing list linuxmuster-user@lists.linuxmuster.net > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVCIyWAAoJEAZn9GjsFwQnIj4QALQLJiS+PC211OFqpHISDh9N 7JWkXC5ndXBHVrGt7VLoepRkgGLe5ofXxRdcSrgg7VrOO2fBHW1AJsKfyACDalJF nulYY/U7y20Wh2sNcxBWZwRYiry/gb84hwIOK3ruIQG9DVRisv85OmkJ5hDYwjVV 3XZMSxQp+aI9GE0Y2p0U+fg+gWKKfOvHL9J942mqvytdUcmBzlDX6hAI7Xx3ZK8U DMcOPsUQ4oOFk6jyajtApl1GNgRPMe43zIThI9H1k0e9DZNp5ii7BWE7KYMjasEs fuF+hIROHQtNLJYCq9tWN0FNn24CjGfg+SA8SnZblW8GhNyoQETza8H2GHoBZKZv 34H91C0z/PCU4Shn+qzT1fHckIiu1V1yWo380KAo9wS+xUqe3HINrPV9CHR1WmSE sWhappT8VyQb2s1JFfnbrBJTuqMj8nATLzCzcHvfngPs25dwq7N9QUyf2W1zZqtA mjvz2q7Efs/RZZt9NVqnoC80CWJz79ZTN16G1BhmyaRI/S0WpAenN8bfnVW9j8Nt H/EmNfuPlfg/qmEb830YeSDsirVkmBLA2ORRqOHdXDFGVaGF8Awqc0B/3eKW9BVB fexjV9AJXvj9SHjtVo0k/at2iHcBe4HWd3JfpYGtPZny8I8a8oJfwJDovik6a6XX +9LfFAeCzaDmpKvHxgpg =EEPU -END PGP SIGNATURE- ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, herzlichen Dank für deine schnelle Reaktion. Am 17.03.2015 um 18:09 schrieb Michael Hagedorn: Ok ... ich habe ein Bsp gefunden... .diese URL habe ich soeben in die Aufnahmeliste gepackt und firefox/java sogar neu gestartet --- es bleibt aber dabei, dass das Applet nicht geladen wird :( bei mir schon (nachdem ich es in die Ausnahmeliste eingetragen habe) http://verein.ai.ch/gym/fachsch/physik/schwingung.htm#top Ich habe es allerdings schon benutzt ... daher _muss_ es an aktuellen Java-Versionen liegen. Ich habe bei meiner "Einrichtung" hier zu Hause ein aktuelles Java - dachte ich zumindest. Mein letztes Java-Update war am 15.02.2015 - für mich ist das aktuell genug. ;) Auf jeden Fall hat es sich ohne Probleme überreden lassen, diese(s) Seite/Applet anzuzeigen. Ich habe jeden Schritt als Screenshot festgehalten und auf dieser Seite bereitgestellt. Auch die HTML-Seite und die class-Datei bereiteten kein Problem (auf der Seite ganz unten). http://www.erasmus-reinhold-gymnasium.de/java/applet.html Ich kann zwar auch nochmal aktualisieren, aber da wird sich m.E. trotzdem nichts an der Situation ändern. Allerdings ist der Unterschied: ich habe hier zu Hause Windows7. Aber das sollte doch auch unter Linux genauso gehen - hoffe ich doch. Es ist (meiner Meinung nach) aber auch (unter Linux) nicht elegant gelöst, dass man die Ausnahme nicht einfach durch anklicken "Erlauben und merken" laufen lassen kann!? Das "java control panel" starte ich per "javaws" ... und muss mich dann umständlich durchklicken und die Ausnahme hinzufügen. Meiner Meinung klappt es auch nicht, einfach eine komplette Domain wie www.leifiphysik.de hinzuzufügen und zu hoffen, dass das Problem damit behoben ist Es muss die URL der _Seite_ sein. Und wenn das Applet nicht im gleichen Verzeichnis wie die Seite liegt, dann muss man sogar 2 Ausnahmen eintragen. Wäre sicherlich einfacher zu lösen gewesen, aber trotzdem: es ist (für jede Seite) nur einmal zu tun. Insofern sind alle anderen Lösungen im Vergleich dazu entweder sicherheitstechnisch kaum zu verantworten oder aus meiner Sicht deutlich aufwendiger. Ich bleibe dabei: Java war schon mal _DEUTLICH_ anwenderfreundlicher. alle Dienste waren deutlich anwenderfreundlicher, als man sich nicht um Zertifikate (sprich signieren) kümmern musste, egal ob es nun um http -> https oder imap -> imaps oder DNS -> DNSSEC ist. Sicherheit gibt es nunmal nicht frei Haus. Und wenn Applets sicher sein sollen, dann müssen die signiert sein. In wie weit das mit Zertifikaten vergleichbar ist, bin ich momentan überfragt. Es spielt aber in Bezug auf Sicherheit die gleiche Rolle. Ich gebe dir völlig recht: wenn man auf Sicherheit verzichtet, das ist deutlich anwendungsfreundlicher. Einen Gefallen hat Oracle den Usern nicht getan --- auch wenn es sicherheitstechnisch notwendig war. Die Bewertung würde bei mir anders aussehen, aber das war ja nicht das Problem. Für mich sieht es eigentlich so aus, dass genau diese Lösung bei mir (unter Windows) funktioniert und bei dir (unter Kubuntu) nicht. Wie könnten wir das Problem weiter eingrenzen? Soll ich mal ein KUbuntu installieren? viele Grüße Hans-Dietrich ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, Am 17.03.2015 um 17:21 schrieb Michael Hagedorn: > Hallo Dirk >> export JAVA_HOME=/usr/java/jdk1.x.x.x.x/bin/java; export >> PATH=$PATH:/usr/java/jdk1.x.x.x.x/bin; java -jar equilibriumforces_de.jar > Wunderbar für Linux - danke. > Gibt es entsprechendes auch in der Klickibunti-Welt -- oder muss man da bei Windows (XP) sind die Einträge in Registry. Es geht aber auch anders; der Einzeiler: Wechselt ins Laufwerk "Z:" ins Verzeichnis "\Downloads" Die Befehlstrenner: & Z: & cd \Downloads & set JAVA_HOME=C:\Programme\Java\jre6 & set PATH=%PATH%;C:\Programme\Java\jre6\bin & C:\Programme\Java\jre6\bin\java -jar equilibriumforces_de.jar Dirk ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Ok ... ich habe ein Bsp gefunden... .diese URL habe ich soeben in die Aufnahmeliste gepackt und firefox/java sogar neu gestartet --- es bleibt aber dabei, dass das Applet nicht geladen wird :( http://verein.ai.ch/gym/fachsch/physik/schwingung.htm#top Ich habe es allerdings schon benutzt ... daher _muss_ es an aktuellen Java-Versionen liegen. Es ist (meiner Meinung nach) aber auch (unter Linux) nicht elegant gelöst, dass man die Ausnahme nicht einfach durch anklicken "Erlauben und merken" laufen lassen kann!? Das "java control panel" starte ich per "javaws" ... und muss mich dann umständlich durchklicken und die Ausnahme hinzufügen. Meiner Meinung klappt es auch nicht, einfach eine komplette Domain wie www.leifiphysik.de hinzuzufügen und zu hoffen, dass das Problem damit behoben ist Ich bleibe dabei: Java war schon mal _DEUTLICH_ anwenderfreundlicher. Einen Gefallen hat Oracle den Usern nicht getan --- auch wenn es sicherheitstechnisch notwendig war. Michael ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, Am 17.03.2015 um 17:36 schrieb Michael Hagedorn: Hallo. Danke für die Infos ... bisher fand ich Java(-Applets) aus vielen Gründen nicht sooo schlecht (plattformübergreifend usw), aber ich finde, dass gerade dieses ewige "geht nicht mehr"-Geklicke ein sehr nerviges und vor allem abschreckendes Beispiel (geworden) ist, wie man's kompliziert machen kann ... ich habe (für Informatik in der Abiturstufe) derzeit 4 Applets in der Ausnahmeliste und die gehen. Wobei natürlich 4 nicht gerade viele sind. Aber es sollen ja auch Ausnahmen bleiben. die Ausnahmeliste kenne ich; leider funktioniert das aber nicht immer (!??!!). Es gibt Applets, die vor einiger Zeit noch liefen und jetzt ! Fehler, Klicken Sie hier um weitere Informationen zu erhalten (was dann aber nicht funktioniert oder nichts gescheites anzeigt) das würde mich aber sehr interessieren (Screenshot?) Und es ist zumindest nur ein einmaliger Eintrag. Auch da habe ich diverse Seiten, die ich zwar eingetragen habe - die dann aber trotzdem nicht funktionieren. Ich suche mal was raus ... Dafür wäre ich dir sehr dankbar. dauert aber etwas, da ich z.T. auch auf offline-jar-Dateien zugreifen möchte (die übrigens auch nicht mehr laufen)) das offline-Dateien nicht mehr laufen kann ich mir momentan nicht erklären. Auch hier wäre ich für ein konkretes Beispiel dankbar. Gerne auch per PM. - Aber es eilt bei mir nicht. Bei mir funktionieren die Ausnahmen, andere Lehrer haben bei uns derzeit wohl keinen Bedarf bzw. keine Probleme. Viele Grüße Hans-Dietrich ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo. Danke für die Infos ... bisher fand ich Java(-Applets) aus vielen Gründen nicht sooo schlecht (plattformübergreifend usw), aber ich finde, dass gerade dieses ewige "geht nicht mehr"-Geklicke ein sehr nerviges und vor allem abschreckendes Beispiel (geworden) ist, wie man's kompliziert machen kann ... die Ausnahmeliste kenne ich; leider funktioniert das aber nicht immer (!??!!). Es gibt Applets, die vor einiger Zeit noch liefen und jetzt ! Fehler, Klicken Sie hier um weitere Informationen zu erhalten (was dann aber nicht funktioniert oder nichts gescheites anzeigt) > Und es ist zumindest nur ein einmaliger Eintrag. Auch da habe ich diverse Seiten, die ich zwar eingetragen habe - die dann aber trotzdem nicht funktionieren. Ich suche mal was raus ... dauert aber etwas, da ich z.T. auch auf offline-jar-Dateien zugreifen möchte (die übrigens auch nicht mehr laufen)) Michael -- Systemdaten: - virtualisiert mit Proxmox 2.3 - linuxmuster.net 6.0.46 - IPFire 2.15 - Linbo 2.1.10-0 - Ubuntu 14.04 Clients (trusty714-Vorlage) - leoclient1 mit WinXP im offline-Modus - Moodle 2.7 (extern mit LDAPS und openLML-Modul) ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, Am 17.03.2015 um 10:37 schrieb Michael Hagedorn: Hallo. Wer kennt das Problem nicht -- da will man ein Java-Applet zur Visualisierung zeigen und von heute auf morgen läuft es nicht mehr, da Java mal wieder ein Update bekommen hat und die Sicherheitsrichtlinien wieder verschärft wurden. Das trifft m.E. die Situation nicht wirklich. Es geht darum, das ab Java 7 Update 51 Java keine Ausführungen von Anwendungen mehr zuläßt, die - nicht signiert oder selbstsigniert (nicht von einer vertrauenswürdigen Quelle signiert) sind - oder denen Berechtigungsattribute fehlen. Das ist ein Schritt, aber nicht "wiedermal" oder gar laufend. Es kommt hinzu, dass sehr viele Applets auch nicht laufend erneuert/angepasst werden und sie somit faktisch nicht mehr benutzbar sind, obwohl sie z.T. sehr brauchbar waren... genauer: wenn es nicht signiert ist, dann ist es auch nicht sicher. Ihr kennt PGP, wen muss ich das erzählen? Für den laufenden Unterricht taugt es natürlich nicht, wenn man sich an irgendwelchen Maßnahmen zur Korrektur versucht. Hast du Zugriff auf die Server, wo die Applets abgelegt sind und hast bzw. willst die Applets signieren? - kann ich mir nicht so richtig vorstellen. ;) Daher habe ich schon länger darüber nachgedacht, wie man eine alte und von mir aus löchrige und sicherheitstechnisch höchst bedenklich ABER FUNKTIONIERENDE (!!) Java-Version konservieren und bei Bedarf hervorzaubern kann?? Aber nicht doch! Wenn DU der Meinung bist, dass es ein Applet gibt, dass zwar nicht signiert ist und damit völlig zurecht als unsicher gilt, aber du das brauchst und du dafür die Verantwortung übernimmst, dann brauchst du doch nur _dieses_ Applet in die Ausnahmeliste von Java einzutragen und das aktuelle Java wird dieses unsichere Applet sehr wohl ausführen. Aber eben nur das, für welches DU die Ausnahme eingetragen hast. Ich bin kein Fan von Java. In meinen (Informatik-)Unterricht stelle ich gerade um von Java auf eine Interpretersprache. Aber trotzdem: diese Strategie von Oracle ist aus meiner Sicht nicht schlecht. Man muss aber eben die Verantwortung für das Applet übernehmen nämlich an der Stelle, wenn man das Applet in die Ausnahmeliste einträgt. Es könnte von mir aus eine VBox sein, die keine Java-Updates abfragt oder was auch immer. Von mir aus kann es auch ein uraltes Java 6 sein -- alles ganz egal. Hauptsache es läuft (!) und zeigt kurz das Applet. Anschließend kann man's ja wieder deaktivieren/ausschalten. Wie habt ihr das geregelt? wie gerade angegeben. Und es ist zumindest nur ein einmaliger Eintrag. Bei deiner Version müßte man bei jeder Nutzung vorher und hinterher die Java-Versionen ändern, also letztlich das BS manipulieren. Das kann doch nicht wirklich gut sein - oder habe ich dich falsch verstanden? Anleitungen für das Eintragen der Ausnahme finden sich z.B. hier: https://www.java.com/de/download/help/java_blocked.xml bei "WORKAROUND" https://support.mozilla.org/de/kb/wie-sie-java-verwenden-wenn-es-gesperrt-wurde bei "Java immer für eine bestimmte Seite aktivieren" Michael Viele Grüße Hans-Dietrich ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Dirk > export JAVA_HOME=/usr/java/jdk1.x.x.x.x/bin/java; export > PATH=$PATH:/usr/java/jdk1.x.x.x.x/bin; java -jar equilibriumforces_de.jar Wunderbar für Linux - danke. Gibt es entsprechendes auch in der Klickibunti-Welt -- oder muss man da auf Cygwin zurückgreifen? Michael ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Am 17.03.2015 um 10:37 schrieb Michael Hagedorn: > > [Spass mit Java im Browser] bei diesem Beispiel http://www.walter-fendt.de/ph6de/equilibriumforces_de.htm kannst Du bspw. das Javaprogramm (.jar) und die Datei mit den Initialwerten laden http://www.walter-fendt.de/ph6de/ph6de_jar/equilibriumforces_de.jar http://www.walter-fendt.de/ph6de/ph6de_jar/equilibriumforces.txt und mit dem Aufruf 1) java -jar equilibriumforces_de.jar starten. Bei mehreren installierten Javaversionen kannst Du mit vorangestelltem export-Anweisungen explizit auf eine Javaversion verweisen: 2) export JAVA_HOME=/usr/java/jdk1.x.x.x.x/bin/java und 3) export PATH=$PATH:/usr/java/jdk1.x.x.x.x/bin Aus 1), 2) und 3) folgt export JAVA_HOME=/usr/java/jdk1.x.x.x.x/bin/java; export PATH=$PATH:/usr/java/jdk1.x.x.x.x/bin; java -jar equilibriumforces_de.jar Dieser Einzeiler verändert nur für den aktuellen Programmlauf die Variablen. Eine persistente Änderung kann in der .bash_profile vorgenommen werden. Dirk ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hi, also auf meinem (Linux) Rechner kann ich - wenn ich mich recht erinnere - von der Shell als root mit update-alternatives --config mozilla-javaplugin.so die Java-Version auswählen, die verwendet werden soll ... ist zumindest mal einen Versuch wert :) VG Wolfgang Am 17.03.2015 um 10:37 schrieb Michael Hagedorn: Hallo. Wer kennt das Problem nicht -- da will man ein Java-Applet zur Visualisierung zeigen und von heute auf morgen läuft es nicht mehr, da Java mal wieder ein Update bekommen hat und die Sicherheitsrichtlinien wieder verschärft wurden. Es kommt hinzu, dass sehr viele Applets auch nicht laufend erneuert/angepasst werden und sie somit faktisch nicht mehr benutzbar sind, obwohl sie z.T. sehr brauchbar waren... Für den laufenden Unterricht taugt es natürlich nicht, wenn man sich an irgendwelchen Maßnahmen zur Korrektur versucht. Daher habe ich schon länger darüber nachgedacht, wie man eine alte und von mir aus löchrige und sicherheitstechnisch höchst bedenklich ABER FUNKTIONIERENDE (!!) Java-Version konservieren und bei Bedarf hervorzaubern kann?? Es könnte von mir aus eine VBox sein, die keine Java-Updates abfragt oder was auch immer. Von mir aus kann es auch ein uraltes Java 6 sein -- alles ganz egal. Hauptsache es läuft (!) und zeigt kurz das Applet. Anschließend kann man's ja wieder deaktivieren/ausschalten. Wie habt ihr das geregelt? Ach ja: Den Vorschlag "Dann zeigt man so ein Applet eben nicht mehr!" braucht übrigens keiner zu posten -- den kenne ich schon :) Michael ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
Re: [lmn] Java konservieren (nicht mehr laufende Applets)
Hallo Michael, meinst Du so was nettes wie hier? http://www.walter-fendt.de/ph6de/equilibriumforces_de.htm Ich habe OpenJDK 7 (in unserem HULC das einzige systemweit verfügbare Java) in den Policies bei linuxadmin so eingestellt, dass es drei Mal fragt, ob es dieses Applet wirklich ausführen darf. Gruß Jürgen Am 17.03.2015 um 10:37 schrieb Michael Hagedorn: > Hallo. > Wer kennt das Problem nicht -- da will man ein Java-Applet zur > Visualisierung zeigen und von heute auf morgen läuft es nicht mehr, da > Java mal wieder ein Update bekommen hat und die Sicherheitsrichtlinien > wieder verschärft wurden. Es kommt hinzu, dass sehr viele Applets auch > nicht laufend erneuert/angepasst werden und sie somit faktisch nicht > mehr benutzbar sind, obwohl sie z.T. sehr brauchbar waren... > > Für den laufenden Unterricht taugt es natürlich nicht, wenn man sich > an irgendwelchen Maßnahmen zur Korrektur versucht. Daher habe ich > schon länger darüber nachgedacht, wie man eine alte und von mir aus > löchrige und sicherheitstechnisch höchst bedenklich ABER > FUNKTIONIERENDE (!!) Java-Version konservieren und bei Bedarf > hervorzaubern kann?? Es könnte von mir aus eine VBox sein, die keine > Java-Updates abfragt oder was auch immer. > Von mir aus kann es auch ein uraltes Java 6 sein -- alles ganz egal. > Hauptsache es läuft (!) und zeigt kurz das Applet. Anschließend kann > man's ja wieder deaktivieren/ausschalten. > > Wie habt ihr das geregelt? Ach ja: Den Vorschlag "Dann zeigt man so > ein Applet eben nicht mehr!" braucht übrigens keiner zu posten -- den > kenne ich schon :) > > Michael > > > ___ > linuxmuster-user mailing list > linuxmuster-user@lists.linuxmuster.net > https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user > ___ linuxmuster-user mailing list linuxmuster-user@lists.linuxmuster.net https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
