Der IE geht – eine kurze Erinnerung an die Browserkriege ⚔

Das die Tagesschau über Software berichtet ist in einer Zeit, in der die IT die Gesellschaft allmählich völlig durchdrungen hat, nicht ungewöhnlich. Aber wenn es um eine so alte Software geht dann doch: Der Internet Explorer geht in Rente und das nach einer 25-jährigen Geschichte.

Logo des Internet Explorers

Ich kann mich nicht mehr erinnern jemals ein aktiver Nutzer des IEs gewesen zu sein und bilde mir heute ein nach ersten Schritten im WWW mit Mosaic im Studium relativ schnell auf den Netscape Navigator gewechselt zu haben, und dann ohne ‚Umweg‘ auf das freie Folgeprodukt Mozilla Firefox. Seit dem Erscheinen von Google Chrome ist dies bis heute mein Hauptwebbrowser.

Aber als Webentwickler kam man lange nicht am Internet Explorer vorbei, jedenfalls für die Zeit, in welcher der IE – insbesondere in der ‚ewigen‘ Version 6 – die absolute Dominanz im Web hatte:

Graphik Browser Wars, Von Wereon - Image:Browser Wars.png, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1128061
Von Wereon – Image:Browser Wars.png, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=1128061

Bis 2002 hatte Microsoft mit seinem Browserprodukt durch die später von Gerichten bestrafte Bündelung mit dem Windows Betriebssystem den zuvor dominierenden Netscape Browser vom Markt gedrängt, damit den ersten Browserkrieg gewonnen und danach die Weiterentwicklung faktisch eingestellt und so die Fortentwicklung des Webs quasi eingefroren. Für viele Webentwickler*innen war es daher die einfachste Lösung Webseiten zu entwickeln, die sich nur auf diese Webbrowser konzentrierten. Noch heute findet man Seiten mit diesem damals allgegenwärtigem Hinweis:

Webseite mit dem Hinweis 'The layout of these pages is optimized for Internet Explorer 800 x 600'

In Deutschland war die Dominanz nie ganz so stark, insbesondere nicht im Umfeld der Hochschulen, da sich hier viele Verfechter von Open Source Produkten fanden und finden, und daher Firefox teilweise bis heute der Standardwebbrowser ist. Trotzdem konnte es einem auch in den 2010er Jahren noch passieren einem Bankberater gegenüber zu sitzen, der den Kreditvertrag in seiner Bankingsoftware in einer alten Version des Internet Explorers bearbeitete, da gerade im Finanzbereich die proprietäre ActiveX Technologie, die sich nur im IE nutzen ließ, im Einsatz war.

Auch der 2. Browserkrieg ist vorbei

Mit dem Aufstieg von Chrome begann der 2. Browserkrieg, der ebenfalls schon lange beendet ist, wie ein Blick in die heutige Verteilung der Webbrowsernutzung zeigt:

Verteilung der Webbrowser Nutzung

By StatCounter generated image - https://gs.statcounter.com/browser-market-share#monthly-202011-202011-bar, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=96191667
By StatCounter generated image – https://gs.statcounter.com/browser-market-share#monthly-202011-202011-bar, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=96191667

Microsoft hat nach letzten, gescheiterten Versuchen mit einem eigenständigen Browserprodukt die alte Dominanz zu erhalten mit dem aktuellen Edge Browser ebenfalls auf die Chromium Basis aufgesetzt, wie es der Opera Browser bereits seit 2013 tut. Jenseits der Apple Welt sind damit die Chromium-Browser heute ähnlich dominant, wie es vor langer Zeit der IE war. Allerdings ohne den Versteinerungseffekt, nun wird das Web in 6-Wochen-Zyklen weiterentwickelt, bald sogar alle 4 Wochen.

Tomcat 10 bringt EE9 – und den Big Bang weg von javax.servlet.*

Bei der kleinen Docker-Bastelei im Anti-DoS-Valve-Projekt wollte ich das Projekt ‚gerade mal eben‘ auf Tomcat 10 hochziehen und bin direkt über eine wesentliche Änderung gestolpert, die mir bisher entgangen war:

Was bisher

import javax.servlet.*;

war muss nun

import jakarta.servlet.*;

sein 😮 Da sich das mit meinen Gehversuchen mit Docker überschnitt hat es einen Moment gebraucht um zu verstehen, wo eigentlich das Problem lag…

Was ist der Hintergrund

Natürlich das Urheberrecht und Oracle’s Wille die mal mit dem Kauf von SUN an Java gewonnenen Rechte auf keinen Fall Preis zu geben. Die entscheidenden Weichenstellungen sind dabei schon weit vor der Niederlage gestellt worden, die Oracle letztlich Anfang April 2021 in der Auseinandersetzung mit Google über die Java Nutzung in Android erlitten hat. Hier sind ein paar Quellen:

Der Artikel der Eclipse Foundation enthält diese Passage, die das Ende der Verwendung von javax.* ankündigt:

‘..Eclipse and Oracle have agreed that the javax package namespace cannot be evolved by the Jakarta EE community. As well, Java trademarks such as the existing specification names cannot be used by Jakarta EE specifications.’

Selbst der Name Java darf nicht mehr in den Spezifikationen wie JPA verwendet werden, die die Eclipse Foundation weiterentwickelt. Bei der Frage wie es nach EE8 weitergehen kann deutet sich die Entwicklung schon an:

‘What happens beyond Jakarta EE 8?

The guiding principle for Jakarta EE 9 will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation.  This will most likely involve two key topics: migration of some or all of the Jakarta EE specification source to a new namespace for future evolution; means to provide backwards compatibility with javax at a binary level, allowing old applications to run on Jakarta 9 implementations with some form of build or runtime tooling.

So while there will be a point in time where future versions of specifications will have to go through a source code incompatible change with respect to the previous javax based packages, this will be a straightforward transformation.’

Eine Frage war es dann ob die Migration weg von javax.* inkrementell erfolgen würde – also nur der Teile, die Veränderungen unterliegen – oder als Big Bang gemacht wird. Die Antwort liefert der vergleichende Blick in die Javadocs der Servlet 4 und 5 APIs:

Der Post Jakarta EE 9 Delivers the Big Bang im Life at Eclipse Blog beschreibt das Vorgehen noch einmal zum Start von EE9. Die Logik dahinter – es wird ein klarer Schnitt gemacht – finde ich durchaus nachvollziehbar. Aber was macht man nun mit Anwendungen, die auf großen Codebasen sitzen und diverse externe Pakete verwenden, die alle noch nicht umgestellt sind?

Was tun mit den Altanwendungen (in Tomcat)

Alles was vor EE9 an Webanwendungen entwickelt wurde ist damit nun plötzlich eine migrationsbedürftige ‚Altanwendung‘. Aber selbst die Befürworter*innen des Big Bangs erkennen an, dass das JEE Ökosystem einfach zu groß ist, als das man innerhalb kürzester Zeit von allen Anbieter*innen von Servern, Anwendungen, Paketen ein Mitziehen erwarten könnte. Es sind also Übergangslösungen gefragt.

In des Migrationshinweisen von Tomcat 10 widmet sich ein eigener Abschnitt dem Thema und es zeigt sich, dass das Tomcat Migration Tool for Jakarta EE, welches im Kern den Eclipse Transformer enthält, hier eingebaut ist und man seine Anwendungen offenbar ohne Umbauten weiterhin deployen kann. Aber nicht mehr in der gewohnten Weise:

Bei einem Test mit einer winzigen JEE Anwendung (nur ein Servlet) in deren pom.xml die Servlet API 4 referenziert wird

                <dependency>
                        <groupId>javax.servlet</groupId>
                        <artifactId>javax.servlet-api</artifactId>
                        <version>4.0.1</version>
                        <scope>provided</scope>
                </dependency>

scheint das Deployment durch Kopieren der WAR-Datei in den <CATALINA_HOME>/webapps-Order zunächst wie gewohnt zu arbeiten, die Datei wird entpackt und die statische Startseite wird im Browser angezeigt. Der Aufruf des Servlets scheitert aber mit einer 404-Meldung, jedoch ohne eine Fehlermeldung in den Tomcats-Logs 🤔

Das Deployment funktioniert erst, wenn man wie in der Migrationshilfe beschrieben einen <CATALINA_HOME>/webapps-javaee-Order anlegt und die WAR Datei dort platziert. Dann passiert beim Start das hier:

Tomcat 10 migriert beim Start eine EE8 Anwendung nach EE9

Tomcat bemerkt die ‚Altanwendung‘ und migriert sie in die neue Welt. Das Ergebnis befindet sich dann im üblichen <CATALINA_HOME>/webapps-Order. Bei der Minianwendung hat das problemlos funktioniert. Die spannende Frage ist dann wie es sich mit komplexeren Anwendungen verhält.

Noch nicht klar geworden ist mir aber ob man bei der Weiterentwicklung von Altanwendungen nun erst einmal auf Tomcat Versionen <10 festgelegt ist, oder ob es auch da einen Weg gibt mit dem aktuellen Tomcat weiter zu machen.

Fazit

Das sich die Eclipse Foundation dazu entschieden hat die Verbindungen zu Oracle und den Teilen von Java, bei denen Oracle sehr viel Wert darauf legt die eigenen Urheberrechtsansprüche zu betonen, ist sicher ein richtiger Schritt. Aber es wird weltweit viel Arbeit machen die betroffenen Systeme auf allen Ebene darauf umzustellen.

Bis sich dieser Aufwand dann gelohnt haben wird, wird viel Zeit ins Land gehen. Und wer weiß ob es nicht Fälle gibt in denen dieser Aufwand das noch fehlende Argument liefert sich von Java im Backend abzuwenden.

Release 1.3.0 des Anti-DoS-Valves – mit Docker

Heute habe ich ein neues Release des Apache Tomcat Valves zur Begrenzung von massenhaften Zugriffen auf Tomcat Server auf Github veröffentlicht. Funktional hat sich dabei nicht viel getan, abgesehen von der Anpassung des Codes an Tomcat 10 und den dort nun anders benannten Servlet API Paketen. Aber dazu schreibe ich noch etwas in einem anderen Post. Die wesentliche Verbesserung liegt hier:

Docker Logo

Im /docker-Unterzeichnis des Projekts findet sich nun eine Docker-Konfiguration, mit der sich sehr einfach ein Tomcat 10 Server mit einkonfiguriertem Valve und einer Testmöglichkeit als Containerinstanz starten lässt. Entweder um das Ganze einmal schnell auszuprobieren, oder um bei eigenen Weiterentwicklungen ohne Basteleien und manuelles Hin- und Herschieben von JARs und Konfigurationen schnell die letzte Version des Valves direkt ausführen zu können.

Ich bin noch nicht so routiniert mit Docker, daher gehe ich hier einmal die Inhalte des /docker-Verzeichnisses durch und falls eine Leserin oder ein Leser dazu Verbesserungsvorschläge hat freue ich mich:

Dockerfile

Es ist nahezu leer:

FROM tomcat:10-jdk16-corretto

Nur das Tomcat 10 Image von Dockerhub wird referenziert. Ich hätte hier schon die angepasste server.xml oder das Valve Jar in das Image bringen können, aber gerade für Entwicklungszwecke erschien es mir zu umständlich jedes Mal ein neues Image zu bauen. Tatsächlich hätte es das Dockerfile im Moment gar nicht gebraucht, es hilft in der jetzigen Form nur die unten beschriebenen Kommandozeilen von späteren Änderungen des verwendeten Tomcat Images zu isolieren.

Falls man aber ein Tomcat Image für produktive Zwecke bauen möchte, in dem das Valve schon enthalten ist, wäre es sicher eine gute Idee die Valve Anpassungen bereits hier zu integrieren und mindestens das Jar schon in das Image aufzunehmen.

README.md

Hier sind die Kommandos enthalten, die es braucht um den Tomcat samt Valve zu starten. Interessant ist dabei eigentlich nur dieses Kommando:

docker run \
   --mount type=bind,source="%cd%"/../target/anti-dos-valve-1.3.0.jar,target=/usr/local/tomcat/lib/anti-dos-valve.jar,readonly  \
   --mount type=bind,source="%cd%"/server.xml,target=/usr/local/tomcat/conf/server.xml,readonly  \
   --mount type=bind,source="%cd%"/advdemo/,target=/usr/local/tomcat/webapps/advdemo/,readonly \
   --name AntiDoSValveDemo \
   -p 8013:8080 \
   -it antidosvalve_demo

In den drei mount-Anweisungen werden drei Dateien/Order aus dem Host-System in den Container abgebildet und überdecken dabei die schon vorhandenen Dateien im Container:

  • JAR: Das Jar, welches sich eins höher im /target-Verzeichnis befindet, wird in das /lib-Verzeichnis des Tomcats im Container gebracht und steht dem Server damit zur Verfügung. Das Jar muss natürlich vorher schon gebaut worden sein
  • server.xml: Hier wird eine angepasste Version der server.xml, die sich im Tomcat Image befindet, in den Container gesetzt. Dadurch werden die Valve Konfigurationen wirksam
  • /advdemo: Dieser Ordner enthält eine JSP – siehe unten – und wird als Webapp eingebracht, die der Tomcat klaglos ausführt

Alle mounts werden als readonly deklariert, damit in keinem Fall der Server im Container etwas zurückschreiben kann. mounts benötigen absolute Pfad, damit die Anweisung trotzdem immer funktioniert wird der aktuelle Pfad eingesetzt. Hier für Windows, für Linux sind entsprechende Anpassungen notwendig.

Es wird ein Portmapping gemacht, dabei wird nicht der sonst übliche Port 8080 verwendet, um nicht in Konflikt mit anderen auf dem Host laufenden Servern zu kommen.

Schließlich wird ein Name vergeben, unter dem sich der Container ansprechen lässt. Das verhindert, dass man einen beendeten Container einfach erneut starten kann und ihn erst entfernen muss. Ich bin mir noch nicht sicher, ob ich das wirklich praktisch finde.

server.xml

Die server.xml Datei, mit der Tomcat 10 Distribution mitgeliefert wird, um 2 Valve Konfigurationen ergänzt. Wenn man alternative Konfigurationen ausprobieren will kann kann man einfach die Datei bearbeiten und den Container neu starten.

/advdemo-Ordner

Hier ist nur eine JSP enthalten, die für die Demonstration des Marking Modes des Valves benötigt wird. Sie wird als eigene Webapp in den Tomcat gebracht und ist dann dort ausführbar.

Schnelle Iterationen

Durch die Containerlösung, die sich in Sekunden hochfährt, ist es einfach neue Versionen des Valves, der server.xml oder auch der JSP auszutesten, deutlich schneller als mir das bisher mit einer separaten Tomcat Instanz möglich war. Auch der rasche Wechsel zwischen unterschiedlichen server.xml Dateien ist einfach, man muss sich nur eine alternative Kommandozeile zurechtlegen. Und dafür ist keine ‚Magic‘ mit in Eclipse und Co. integrierten Tomcats notwendig, alles sind einfache Kommandozeilen, die sich schnell ausführen und und anpassen lassen.

Mir gefällt das gut 😀🐳