JSP pages let developers mix static HTML with dynamic content pulled from Java objects. Custom tags wrap common tasks so the page stays readable instead of filling up with scriptlets. The standard tag library builds on that idea by supplying a ready set of tags for everyday jobs such as looping through collections or showing values safely.
Basics of JSP and custom tags
A JSP file is processed by the servlet container before it reaches the browser. The container turns the page into a servlet that writes out the markup. When you add custom tags you give the page author a simple XML element that hides the Java code behind it. The tag library descriptor file maps each tag name to the supporting Java class. Once the library is declared at the top of the page the tags become available without further setup.
A common starting point is the expression language that works alongside the tags. You can write simple paths like user.name and the container evaluates them against the objects placed in one of the four scopes. This removes most of the need for explicit getter calls in the markup.
Core tags for control flow and data display
The core library supplies tags that replace the control structures normally written in scriptlets. The if tag tests a condition and includes its body only when the test is true. The choose tag together with when and otherwise handles multiple branches in a style similar to a switch statement. For repetition the forEach tag walks over arrays, lists or maps and exposes the current item through a variable you name yourself.
Output is handled mainly by the out tag. It writes the value of an expression and by default escapes XML characters, which helps avoid broken pages when user supplied data contains angle brackets. You can turn escaping off when you know the content is already safe markup.
A short list of situations where these tags are often applied includes building navigation menus from a list of links, showing error messages only when they exist, and rendering rows in a table from a database result.
Features for internationalization
Web applications that reach users in more than one language need a way to swap text and formats without changing the page code. The format library supplies tags that read resource bundles based on the current locale. The message tag pulls a key from the bundle and inserts it at the tag location. Parameters can be passed in so the same message template works for singular and plural forms or for sentences that include numbers.
Date and number formatting tags adjust automatically to the locale setting. A date that appears as month day year in one region will follow day month year order in another without extra code on the page. You set the locale once per request, usually in a filter or listener, and the tags pick it up from there.
When a bundle key is missing the tags can be configured to show the key itself or a default string. This keeps the page from breaking during development when translations are still being added.
Performance considerations
Tags introduce a small amount of work for each use because the container must locate the tag handler and manage its lifecycle. In most cases the cost stays low, yet it adds up when a tag sits inside a loop that runs thousands of times. One practical step is to move repeated calculations out of the page and into a servlet or helper bean so the page only displays a prepared result.
Scope choice also matters. Placing an object in application scope when it could live in request scope keeps it in memory longer than needed. Conversely, reading from session scope on every page hit can cause contention under load. Matching the scope to the actual lifetime of the data reduces both memory use and lookup time.
Some containers compile the expression language into bytecode after the first request. Turning on that option, when available, removes repeated parsing. Keeping the number of custom tags on a single page reasonable also helps the developer who must maintain the markup later.