Editorial illustration.
Originally published 26 June 2023; rewritten and reviewed on 15 October 2026.
The first table usually works with three hard-coded rows. The design becomes clearer when those rows come from a database, can contain user-supplied text and may grow into thousands of records. I would establish the servlet-to-view contract before adding visual features.
Let the servlet prepare the data
Retrieve authorised records through the application’s service or data layer, map them into a view model and attach the collection to the request. Forward to the JSP after the data has been prepared. Avoid opening database connections inside the view.
Do not retrieve every record merely because the first demonstration used a small list. Apply a bounded page size and predictable ordering when the result set can grow.
Render values as text
A JSTL-style view fragment might look like this, assuming the project’s tag library is configured:
<table>
<thead><tr><th scope="col">Customer</th></tr></thead>
<tbody>
<c:forEach var="row" items="${rows}">
<tr><td><c:out value="${row.customerName}" /></td></tr>
</c:forEach>
</tbody>
</table>
The namespace and servlet imports depend on whether the project uses a legacy Java EE or newer Jakarta stack. Do not mix those dependencies casually. c:out is useful here because names should appear as text, not executable markup.
Give the table an operational contract
Handle no results, retrieval errors and invalid page requests explicitly. Sorting and filtering need server-side validation, especially if they influence a query. Include meaningful column headers so the content remains understandable with assistive technology.
Test a name containing angle brackets, an empty collection and the final page of a result set. Those cases reveal more about the implementation than another screenshot of the original three rows. The table is ready when it presents the right records safely and predictably.