JSP (Jakarta Server Pages)

JSP — originally JavaServer Pages, and since the move to the Eclipse Foundation known as Jakarta Server Pages — is a server-side technology for the Java platform that lets developers embed dynamic content directly inside otherwise ordinary HTML (or XML) documents. A JSP page looks like a web page sprinkled with special tags and expressions; when a request arrives, the servlet container translates the page into a Java servlet, compiles it, and runs it to produce the final response. JSP is not a standalone general-purpose programming language so much as a templating layer layered on top of the Java Servlet API, designed to make generating dynamic web pages feel more like authoring documents than writing low-level request handlers.

First released by Sun Microsystems in 1999, JSP was Java’s answer to Microsoft’s Active Server Pages (ASP) and to PHP: technologies that had popularized the idea of writing mostly-HTML pages with bits of code interspersed. JSP brought that convenience to the Java world while retaining Java’s type system, libraries, and the robustness of the servlet model underneath.

History & Origins

Before JSP, dynamic content on the Java platform was generated by servlets — Java classes that build an HTTP response by writing strings to an output stream. Servlets are powerful but awkward for page-heavy work: producing a complex HTML document meant embedding large amounts of markup inside Java println statements, which was tedious and error-prone.

Sun Microsystems introduced JSP 1.0 in 1999 to invert that relationship. Instead of writing Java that emits HTML, developers could write HTML that contains Java. The specification was led inside Sun by engineers including Eduardo Pelegri-Llopart and Larry Cable. The core insight — shared with ASP and PHP — was that for page-oriented work, the document should be primary and the code secondary.

JSP evolved quickly through the Java Community Process. JSP 1.1 appeared in 1999 alongside Servlet 2.2 and added custom tag libraries, allowing reusable logic to be packaged behind XML-like tags. JSP 1.2 (finalized in 2001, under JSR 53) refined that mechanism. JSP 2.0 (JSR 152, around November 2003) was a landmark release that introduced the Expression Language (EL) and tag files, sharply reducing the need for raw Java in pages. JSP 2.1 (JSR 245, 8 May 2006) unified its Expression Language with that of JavaServer Faces, and JSP 2.2 (2009) and JSP 2.3 (around 2013) followed as part of Java EE 6 and Java EE 7.

In 2017 Oracle contributed Java EE to the Eclipse Foundation, which rebranded the platform Jakarta EE. Because Oracle kept the Java trademark, JavaServer Pages was renamed Jakarta Server Pages. The most visible technical consequence came with Jakarta Server Pages 3.0 (around October 2020, part of Jakarta EE 9), which renamed the API package namespace from javax.servlet.jsp.* to jakarta.servlet.jsp.*. Development has continued under Eclipse stewardship with 3.1 (around 2022) and 4.0 (April 2024).

Design Philosophy

JSP is built on a handful of guiding ideas:

• Documents first, code second. A JSP file is fundamentally a template. Static markup passes through untouched; only the dynamic parts require special syntax.
• Compile, do not interpret. Each JSP page is translated into a Java servlet source file and then compiled to bytecode the first time it is requested (and recompiled when it changes). At runtime a JSP is just a servlet, so it inherits the performance and type safety of compiled Java.
• Separation of concerns. Over time JSP’s philosophy shifted firmly toward keeping business logic out of pages. Modern guidance is to use tag libraries and the Expression Language for presentation and to delegate real logic to servlets, beans, and frameworks — the classic Model-View-Controller arrangement where JSP is strictly the View.
• Extensibility through tags. Rather than growing an ever-larger built-in vocabulary, JSP lets developers and libraries define custom tags, giving the language an open-ended, declarative way to add capabilities.

Key Features

JSP pages combine several distinct syntactic elements:

• Template text — ordinary HTML/XML that is sent to the client verbatim.
• Directives (<%@ ... %>) — page-level instructions such as page, include, and taglib that configure compilation and import tag libraries.
• Scriptlets (<% ... %>), expressions (<%= ... %>), and declarations (<%! ... %>) — embedded Java. These were central to early JSP but are now widely discouraged in favor of EL and tags.
• Expression Language (EL) — a compact syntax such as ${user.name} for reading data from beans, request attributes, and other scopes without writing Java.
• Standard and custom tags — the JSP Standard Tag Library (JSTL) provides tags for iteration (<c:forEach>), conditionals (<c:if>), formatting, and more, while custom tag libraries package application-specific behavior.
• Implicit objects — predefined variables such as request, response, session, application, and out that expose the servlet environment to the page.

A small example illustrates the modern, scriptlet-free style:

<%@ taglib prefix="c" uri="jakarta.tags.core" %>
<html>
<body>
  <h1>Hello, ${param.name}!</h1>
  <ul>
    <c:forEach var="item" items="${cart.items}">
      <li>${item.title} — ${item.price}</li>
    </c:forEach>
  </ul>
</body>
</html>

Evolution

JSP’s trajectory mirrors the broader maturation of Java web development. The earliest pages were heavy with scriptlets — pages that mixed markup, SQL, and business logic into a single hard-to-maintain file. The arrival of JSTL (2002) and the Expression Language (JSP 2.0, 2003) gave developers declarative alternatives, and the community consensus quickly turned against scriptlets entirely. Frameworks such as Apache Struts and later Spring MVC adopted JSP purely as a view technology behind a proper controller layer.

JSP also gave rise to, and was eventually overshadowed by, more component-oriented approaches. JavaServer Faces (JSF) originally built its component tree on top of JSP before moving to its own view technology (Facelets). Outside the Java ecosystem, the JSP model directly inspired Groovy Server Pages (GSP) used by the Grails framework.

The Jakarta era has been about modernization and stewardship rather than dramatic new features: the namespace migration in 3.0, dependency and tooling updates, and the deprecation of legacy elements like <jsp:plugin> (used in the applet era).

Current Relevance

JSP is firmly in its maintenance and legacy-support phase rather than a growth phase. New green-field Java web applications increasingly favor template engines such as Thymeleaf, FreeMarker, or client-side single-page-application frameworks backed by JSON APIs (commonly built with Spring Boot). Even so, JSP remains an actively maintained specification within Jakarta EE, with the 4.0 specification released in April 2024 as part of Jakarta EE 11, and it is supported out of the box by most major servlet containers — Apache Tomcat, Jetty, WildFly/JBoss, GlassFish, Open Liberty, and Oracle WebLogic among them.

The most important reason JSP still matters is the enormous installed base. Two decades of enterprise, banking, telecom, and government systems were built on Struts-and-JSP or Spring-and-JSP stacks, and a great deal of that software is still in production and under active maintenance. Knowing JSP remains a practical skill for anyone working with established Java web codebases.

Why It Matters

JSP was one of the defining technologies of the first wave of Java web development. It established the pattern — now ubiquitous across the industry — of an HTML-first template that is compiled and executed on the server, and it pushed the Java community toward the Model-View-Controller separation that underpins modern web frameworks. Its tag-library and Expression-Language ideas influenced a generation of view technologies both inside and outside the Java world. Whether viewed as a still-useful tool, a maintained standard, or a piece of computing history, JSP occupies an important place in the story of how the web learned to serve dynamic pages at scale.