Rüdiger Plantiko

Zurück
Applets can only phone home hiess es im Javabuch von Cornell und Horstmann: Um Missbrauch zu vermeiden, sollte ein Applet HTTP-Requests nur an die Domäne richten können, von der es abgerufen wurde. Aber immerhin diese Art von Requests, das Telefonieren nach Hause, war bis Java 5 problemlos möglich, auch mittels JavaScript-Java-Kommunikation. Bevor Ajax im Web omnipräsent wurde, hatte ich daher ein unsichtbares Applet als Telefonapparat benutzt, um von JavaScript aus Requests an den Server zu senden:
class HttpRequestor extends Applet {
  public String doRequest(String urlstring) {
    String response = "";
    String line = "";
    try {
      URL url = new URL( urlstring );
      BufferedReader in = new BufferedReader(new InputStreamReader( url.openStream() ));
      String line;
      while ((line = in.readLine()) != null)
        response += line + "\n";
      return response;
      } 
    catch (Exception ex) {
       return ex.getMessage();
       }
    }
  }
Leider erodiert Software, wenn man nicht nach ihr schaut. Ein Jahr vergeht, und noch eins... und plötzlich entscheidet ein Sicherheitsbeauftragter bei Oracle, genau diese Art von Requests zu verbieten. JavaScript-Code, der obige Methode aufruft, ist dann einfach kaputt, funktioniert nicht mehr: In der Konsole landet eine Fehlermeldung wie:
access denied (java.net.SocketPermission 91.90.146.25:80 connect,resolve)
Der Frage- und Antwortseite Stack Overflow verdanke ich den Hinweis auf die folgende Lösung: Man hüllt die auszuführende Methode einfach als PrivilegedAction in die Methode AccessController.doPrivileged ein. Dann wird der Request wieder klaglos ausgeführt:
public class HttpRequestor extends Applet {

public String sendRequest(final String urlstring) { return AccessController.doPrivileged( new PrivilegedAction() { public String run() { return doRequest(urlstring); } } ); }

private String doRequest(String urlstring) { String response = ""; String line = ""; URL url; try { url = new URL( urlstring ); BufferedReader in = new BufferedReader(new InputStreamReader( url.openStream() )); while ((line = in.readLine()) != null) response += line + "\n"; return response; } catch (Exception ex) { return ex.getMessage(); } }

}

Aber wie lange wird diese Lösung halten? Wie lange wird es dauern, bis der nächste Mitarbeiter eine ganz arg wichtige, aber leider inkompatible Änderung an der Applet-Infrastruktur vornehmen wird?

Man muss leider zugestehen, dass der Zug für Applets abgefahren ist. Es ist eben auch nur eine Plugin-Lösung, sie haben - wie etwa auch Flash - ihre kleine, eingeschworene Fangemeinde, aber die grosse Mehrheit hat auf pluginfreie Technologien gesetzt. Kein kleines Entwicklerlicht irgendwo in Redwood City wird mal eben die XMLHttpRequest-Technik inkompatibel verändern: Er hätte damit das halbe Web lahmgelegt.

Es hätte mal anders kommen können, wenn die Applets in der Zeit von ca. 1998 bis 2005 offensiver genutzt und vorangetrieben worden wären. Nun sind sie nur noch eine verpasste Chance in der IT-Geschichte.

Ähnlich wird es vermutlich mit Perl 6 gehen. Man kann nicht eine Dekade lang an einem neuen Sprachrelease werkeln und glauben, in der Zwischenzeit würden nicht andere - und mit viel Glanz und Eleganz - die dadurch entstehende Lücke im Bereich dynamischer Sprachen besetzen. Und zwar irreversibel besetzen.

Veröffentlicht: Dienstag, den 20. Dezember 2011