Sie bestellen in einem Restaurant ein Gericht. Was Sie bekommen, ist ein fertiger Teller. Was Sie nie zu sehen bekommen, ist die Küche dahinter: das Schnippeln, das Anbraten, das Abschmecken. Genau so verhält es sich, wenn Ihr Browser eine Webseite anfordert. Er stellt eine Bestellung, und kurz darauf kommt ein fertiger Teller HTML zurück. Wer in der Küche steht, sieht er nie.
JSP ist eine dieser Küchen.
JSP verbindet HTML mit Java und erzeugt serverseitig dynamische Webseiten, die als fertiges HTML an den Browser gehen.
Was ist JSP?
JSP, ausgeschrieben JavaServer Pages, ist eine Java-basierte Technologie, um dynamische Webinhalte zu erzeugen. Geboren wurde sie 1999 bei Sun Microsystems. Seitdem ist viel passiert: Oracle übernahm Sun, übergab die Enterprise-Welt an die Eclipse Foundation, und aus „Java EE“ wurde „Jakarta EE“. Mit diesem Umzug bekam auch JSP einen neuen Nachnamen. Offiziell heißt die Technologie heute Jakarta Server Pages. Wer in einem Projekt auf javax.servlet.jsp stößt, arbeitet mit der alten Welt. Wer jakarta.servlet.jsp liest, mit der neuen. Dieser eine Buchstabenwechsel ist keine Kosmetik. Er entscheidet darüber, welche Bibliotheken und welcher Server zusammenpassen.
Im Kern bleibt JSP, was es immer war: eine Vorlage, in der statisches HTML und dynamischer Java-Code nebeneinander wohnen. Ausgeführt wird das Ganze von einem Servlet-Container wie Apache Tomcat. Der Teller wird also nicht im Browser angerichtet, sondern auf dem Server. Fertig serviert.
Wie funktioniert JSP?
Hier wird es interessant, denn JSP führt den Betrachter ein wenig hinters Licht.
Eine JSP-Datei sieht aus wie HTML mit ein paar fremden Klammern darin. In Wahrheit wird sie beim ersten Aufruf in ein vollwertiges Java-Servlet übersetzt, kompiliert und dann ausgeführt. Erst das Ergebnis dieser Ausführung, sauberes HTML, geht an den Browser. Die Vorlage selbst bleibt in der Küche.
Stellen Sie es sich vor wie eine Rezeptkarte. Beim ersten Mal liest der Koch sie umständlich Zeile für Zeile. Danach sitzt das Rezept in den Händen. Genau das erklärt zwei berühmte Eigenheiten von JSP: warum der allererste Aufruf langsamer ist, und warum eine Fehlermeldung oft kryptisch wirkt. Sie zeigt nämlich nicht Ihre Karte, sondern die übersetzte Fassung.
Ein einfaches Beispiel:
<%@ page contentType="text/html;charset=UTF-8" %>
<html>
<head>
<title>Beispiel für JSP</title>
</head>
<body>
<h1>Hallo, ${param.name}!</h1>
</body>
</html>
Der Name kommt aus der Anfrage und landet im fertigen HTML. Eine kleine Warnung am Rande: Früher schrieb man dafür <%= request.getParameter("name") %> und gab Fremdeingaben ungefiltert aus. Das ist eine offene Tür für Cross-Site-Scripting. Die moderne Schreibweise mit der Expression Language ${...} ist nicht nur kürzer, sie ist auch sicherer. Merke: Eingaben sind keine Zutaten, denen man blind vertrauen sollte.
Die Hauptkomponenten von JSP
JSP kennt vier klassische Werkzeuge, um Java in die Seite zu holen.
Ausdrücke (<%= ... %>) werten einen Java-Ausdruck aus und schreiben das Ergebnis direkt in die Seite. Skriptlets (<% ... %>) erlauben beliebigen Java-Code mitten im HTML. Deklarationen (<%! ... %>) definieren Variablen und Methoden, die der ganzen Seite zur Verfügung stehen. Direktiven (<%@ ... %>) sagen dem Container, wie er die Seite behandeln soll, etwa über page, include oder taglib.
Und hier eine klare Position, die man selten so deutlich liest: Skriptlets sind die größte Falle dieser Technologie. Wer Java-Logik in die Seite kippt, vermischt Küche und Esszimmer. Der Code wird unwartbar, und niemand findet später noch durch. Die professionelle Antwort darauf heißt Expression Language (EL) und JSTL (Jakarta Standard Tag Library). Beide halten die Logik draußen und die Präsentation sauber. Wer heute eine neue JSP schreibt und dabei Skriptlets streut, baut sein Problem von morgen.
Die Vorteile von JSP
Plattformunabhängigkeit. Java läuft überall, also läuft auch JSP überall. Auf dem Mac entwickeln, auf Linux ausliefern, dasselbe Verhalten. Das macht den Einsatz in gemischten Umgebungen leicht.
Trennung von Darstellung und Logik. Im Idealfall bleibt im Esszimmer das HTML, in der Küche der Java-Code. Diese Trennung hält eine Codebasis schlank und wartbar. Sie funktioniert allerdings nur, wenn man sie auch durchhält, siehe oben.
Tiefe Integration in die Java-Welt. JSP spielt mühelos mit Servlets, JDBC für Datenbanken, Webservices und dem übrigen Jakarta-EE-Ökosystem zusammen. Wer ohnehin in Java zu Hause ist, muss nicht umziehen.
Performance nach dem Aufwärmen. Die Übersetzung in ein Servlet passiert einmal. Danach liegt das kompilierte Servlet im Speicher und antwortet schnell. Der Koch hat das Rezept verinnerlicht. Jede weitere Bestellung geht zügig raus.
JSTL als Abkürzung. Statt Schleifen und Bedingungen mühsam in Java zu schreiben, übernehmen fertige Tags die Arbeit. Weniger Code, weniger Fehler, mehr Wiederverwendung.
Die Nachteile von JSP
Fehlersuche, die nervt. Weil Ihre Datei erst zum Servlet wird, zeigen Fehlermeldungen oft die übersetzte Version mit langen, unleserlichen Stack-Traces. Sie suchen einen Tippfehler in Ihrer Rezeptkarte und bekommen das Protokoll des verwirrten Kochs.
Eine Einstiegshürde. JSP ohne Java zu verstehen ist wie Kochen ohne Feuer. Wer die Java-Plattform nicht kennt, kämpft am Anfang.
Träger erster Aufruf. Die anfängliche Kompilierung kostet Zeit. Bei stark frequentierten Anwendungen kann der erste Aufruf nach einem Neustart spürbar zäh sein.
Das Alter. Hier die unbequeme Wahrheit. JSP ist gereift, manche würden sagen ergraut. Die Technologie verführt zu vermischter Logik, und neue Projekte greifen heute selten dazu. Mehr dazu im Fazit.
JSP im Vergleich zu anderen Technologien
JSP gegenüber Servlets. Beide erzeugen serverseitig dynamische Inhalte. Der Unterschied ist die Bequemlichkeit. Ein Servlet ist reiner Java-Code, der HTML zusammenschreibt. Eine JSP ist HTML, das im Hintergrund zum Servlet wird. Anders gesagt: JSP ist die freundlichere Schreibweise für dasselbe Ergebnis. Für seitenlastige Oberflächen ist das ein Segen.
JSP gegenüber ASP.NET. ASP.NET ist Microsofts Antwort auf dieselbe Frage. Das verfolgt vergleichbare Ziele, ist aber eng an das .NET-Framework und an Windows gebunden. JSP punktet dort mit Plattformunabhängigkeit und seiner Verwurzelung in der Java-Welt.
JSP gegenüber PHP. Hier räumen wir mit einem hartnäckigen Irrtum auf. Man liest oft, JSP sei „objektorientiert“ und PHP nicht. Beides stimmt nicht. JSP ist gar keine Sprache, sondern eine Vorlagentechnik, die zu Java-Servlets wird. Objektorientiert ist Java, nicht JSP. Und PHP ist seit Version 5 ebenfalls objektorientiert. Der ehrliche Unterschied liegt woanders: PHP hat eine flachere Lernkurve und einen schnelleren Einstieg. Die Java-Welt rund um JSP bietet dafür strikte Typisierung, eine riesige Standardbibliothek und ein Ökosystem, das auf große, langlebige Anwendungen ausgelegt ist. Zwei Küchen, zwei Philosophien. Nicht besser oder schlechter, sondern für unterschiedliche Speisekarten gebaut.
Wo JSP heute noch kocht
Drei Felder, in denen JSP über Jahre stark war und vielerorts weiterläuft.
In Content-Management-Systemen erzeugt JSP dynamische Inhalte aus Datenbankabfragen: Profile, Artikel, Medienseiten. In E-Commerce-Anwendungen treibt es Produktseiten, Warenkörbe und Kundenbereiche an, oft eng mit der Geschäftslogik verzahnt. Und in Intranets vieler Unternehmen stecken JSP-Anwendungen in Mitarbeiterportalen und Verwaltungstools, dort, wo die Anbindung an Backend-Systeme zählt.
Eines verbindet diese Beispiele: Vieles davon sind heute Bestandssysteme. Sie laufen, sie tragen, und niemand fasst sie ohne Not an.
JSP und SEO
Kann eine serverseitige Technologie der Sichtbarkeit bei Suchmaschinen helfen? Sie kann, wenn man die Erwartungen geraderückt.
Der größte Pluspunkt ist das serverseitige Rendern. Der Suchmaschinen-Crawler bekommt fertiges HTML auf den Teller, nicht eine leere Hülle, die erst im Browser per JavaScript befüllt wird. Das ist ein echter Vorteil gegenüber naiv gebauten Single-Page-Anwendungen. Dazu kommen schnelle Antwortzeiten nach dem Aufwärmen, dynamisch erzeugte Meta-Tags für title und description sowie sauberes, zugängliches Markup über JSTL.
Ein verbreitetes Missverständnis sei aber benannt: JSP allein zaubert keine schönen, schlüsselwortreichen URLs herbei. Die entstehen über das Servlet-Mapping, über URL-Rewriting oder über das eingesetzte Framework, nicht aus der JSP-Datei selbst. Wer das verwechselt, sucht das Gewürz im falschen Schrank.
Fazit
JSP hat ein reales Problem gelöst, und das über zwei Jahrzehnte. Es brachte Dynamik in eine statische Webwelt, lange bevor das selbstverständlich war. Riesige Systeme laufen bis heute darauf, zuverlässig und unaufgeregt.
Doch hier ist der Punkt, an dem ehrliche Beratung anfängt: Für ein neues Projekt im Jahr 2026 greifen die wenigsten Teams noch zu JSP. Sie wählen Spring Boot mit einer Template-Engine wie Thymeleaf, oder sie trennen Backend und Frontend ganz und stellen eine API bereit. JSP zu kennen heißt heute vor allem, bestehende Anwendungen verstehen, warten und behutsam modernisieren zu können. Das ist kein kleines Wissen. Es ist nur ein anderes als früher.
Bleibt eine Frage, die jedes Team für sich beantworten muss: Bauen Sie eine neue Küche, oder kochen Sie weiter in der, die seit Jahren verlässlich liefert?
Weiterführend: die offizielle Jakarta-Server-Pages-Spezifikation der Eclipse Foundation und der Apache Tomcat als verbreiteter Servlet-Container.
