How to use regular Java classes with JSPs

Integrating Java Business Objects into Your JSP Project

When you start building a JSP‑based web application, it’s tempting to cram every piece of logic directly into the page. That approach works for small demos, but as soon as you need to store data, validate inputs, or keep a clean separation between presentation and business logic, the page starts to look like a tangled mess. The trick is to move the heavy lifting into plain Java classes and let the JSP act only as a thin presentation layer. By following this pattern you keep your code maintainable, testable, and scalable.

The core idea is simple: create ordinary Java classes that represent your domain entities and their related operations, compile them, place them in the appropriate directory, and then reference them from the JSP. Because JSPs are compiled at runtime, the Java classes you import must be on the server’s classpath. The most common location for these classes in a Tomcat deployment is WEB-INF/classes or any subdirectory under it that matches the package structure of the classes.

Let’s walk through the process step by step. First, you decide what domain objects you need. In the Email List example, the domain object is a User that contains a first name, a last name, and an email address. You then create a separate class, UserIO, that knows how to persist a User instance to a file or a database. By keeping these responsibilities in distinct classes, you can swap out the persistence mechanism later without touching the JSP.

Next, you write the classes. The User class is a plain POJO (plain old Java object) with private fields, a no‑argument constructor, an overloaded constructor for convenience, and getter/setter methods for each field. You’ll also want to override toString() for debugging, but that’s optional. The UserIO class exposes a static method addRecord that accepts a User and a file path. Inside, you open a PrintWriter in append mode, write the user’s data in a delimited format, and close the writer. The method is marked synchronized to guard against concurrent writes when multiple requests hit the JSP at once. This simple locking prevents data corruption in a multi‑threaded servlet container.

After coding, you compile the classes. You can use an IDE’s build tools, a command‑line compiler, or a text editor that supports Java compilation. The compiled .class files must end up in a directory that matches the package structure. For example, if User is declared in package business, the compiled file must live in WEB-INF/classes/business/User.class. Similarly, UserIO in package data must be in WEB-INF/classes/data/UserIO.class. Any other directory under WEB-INF/classes is acceptable as long as the package hierarchy aligns.

Once the classes are in place, you’re ready to bring them into the JSP. A JSP can import Java packages using the page directive <%@ page import="business., data." %>. After the import, you can instantiate objects, call static methods, and invoke getters and setters all within scriptlets or expression tags. The key is to keep the scriptlet logic minimal: retrieve request parameters, create a domain object, delegate persistence, and render the result using expression tags. This approach preserves a clean separation between the view (HTML) and the business logic (Java), and it keeps the JSP free from complex control flow or data manipulation.

Because JSPs are compiled at runtime, the server needs to have the class files ready when the page is first requested. If you change the Java classes after the JSP has been deployed, you typically need to redeploy the application or restart the server to ensure the latest bytecode is loaded. Tomcat also supports hot deployment of JSPs and classes when you enable the appropriate configuration, but a full restart is still the safest route during development.

In summary, the integration process consists of: identifying domain entities, writing clean Java classes for those entities and their persistence, compiling and deploying the classes to WEB-INF/classes, and importing the packages into the JSP. By following this workflow you create an architecture that is easier to understand, test, and evolve as your application grows.

Designing and Compiling the User and UserIO Classes

The heart of the Email List application lies in two simple yet powerful Java classes. The User class represents a subscriber’s data, while UserIO handles writing that data to persistent storage. The design of these classes follows established Java conventions, making them straightforward to read and extend.

First, let’s examine the User class. It belongs to the business package, reflecting its role as a business object. The class declares three private string fields: firstName, lastName, and emailAddress. Encapsulation is achieved by providing public getter and setter methods for each field. The default no‑argument constructor exists to satisfy JavaBeans conventions and allows frameworks that rely on reflection to instantiate the class. An overloaded constructor takes three parameters - first, last, and email - and assigns them directly to the fields. This constructor is convenient for the JSP, which receives request parameters as strings and can feed them straight into the constructor.

The toString method is omitted in the original code, but adding it can simplify debugging. For example, logging a User instance becomes as easy as System.out.println(user);, revealing the current state of the object without manually concatenating fields.

Next, the UserIO class resides in the data package. It contains a single static method, addRecord, that accepts a User and a file path. The method opens a PrintWriter in append mode using new FileWriter(filename, true), writes a single line that concatenates the user’s email, first name, and last name separated by pipe characters, and finally closes the writer. The pipe delimiter keeps the file human‑readable while allowing simple parsing later.

Thread safety is a consideration in web applications. The synchronized keyword on the method ensures that only one thread can execute addRecord at a time. Without this lock, concurrent requests could interleave write operations, corrupting the file. This is a lightweight solution that suffices for the small scale of the Email List example. For larger systems, a database or a more robust file‑locking mechanism would be preferable.

Compiling these classes requires the Java Development Kit (JDK) to be installed on the machine running Tomcat. If you’re using an IDE such as Eclipse or IntelliJ IDEA, the IDE will compile the classes automatically when you build the project. If you prefer the command line, navigate to the root of the source tree and execute javac -d WEB-INF/classes src/business/User.java src/data/UserIO.java. The -d option directs the compiler to place the generated class files into the specified output directory while preserving the package hierarchy. After compilation, verify that WEB-INF/classes/business/User.class and WEB-INF/classes/data/UserIO.class exist.

When deploying to Tomcat, the WEB-INF/classes directory is automatically added to the web application’s classpath. Therefore, the servlet container can locate the compiled classes at runtime. If you change the source files after deployment, you’ll need to recompile and copy the new class files into the same directories. Some developers prefer to use a build tool like Maven or Gradle to automate this process, but for a small project the manual steps outlined above are sufficient.

By keeping the User and UserIO classes simple, you create a foundation that’s easy to extend. Should you decide to switch from file storage to a relational database, you can replace the contents of UserIO with JDBC code without touching the JSP. If you later need to add validation, you could add methods to User that check for a valid email format or non‑empty names. The separation of concerns ensures that changes ripple only through the parts that actually need them.

Deploying and Invoking Your Classes from a JSP Page

With the Java classes ready and compiled, the next step is to make them available to the JSP that collects user input and displays a confirmation page. The JSP, located in the root of the web application, starts by importing the packages that contain User and UserIO. The import statement looks like this: <%@ page import="business., data." %>. By importing the entire packages, you avoid having to fully qualify class names within the JSP.

The JSP retrieves the form data sent via POST using request.getParameter("firstName"), request.getParameter("lastName"), and request.getParameter("emailAddress"). These calls return String objects that may be null if a parameter was omitted. For simplicity, the example does not perform null checks, but a production system should validate that each field is present and that the email address conforms to a basic pattern. After obtaining the strings, the JSP creates a new User instance by passing the three strings to the constructor. At this point, the User object holds the data in memory.

To persist the data, the JSP calls UserIO.addRecord(user, "WEB-INF/etc/UserEmail.txt"). The path points to a file inside WEB-INF/etc, a directory that is not served directly by the web server. Placing the file here prevents external users from downloading the raw data. If the file does not yet exist, FileWriter will create it automatically, and PrintWriter will append the new record. Because addRecord is synchronized, simultaneous requests will be queued, ensuring that each line is written atomically.

After the data is written, the JSP renders a confirmation page. It uses a simple HTML table to display the values stored in the User object. Expression tags such as <%= user.getFirstName() %> print the current state of the object directly into the HTML. By pulling the values from the User instance rather than from the request parameters, the page guarantees consistency between what was stored and what is shown.

Below the table, the JSP provides a form that submits back to join_email_list.html, allowing the visitor to enter another email address. Because the original form used method="post", each new submission goes through the same JSP logic, creating a new User and adding another record to the file. This loop provides a basic yet functional email list manager.

It’s worth noting that the JSP uses scriptlets - raw Java code embedded in the page - to perform the business logic. Modern JSP development prefers the JavaServer Pages Standard Tag Library (JSTL) or Expression Language (EL) to avoid mixing Java code with HTML. However, for learning purposes and in small projects, scriptlets remain a quick way to access Java objects. If you decide to adopt JSTL, you would replace the scriptlet block with a tag that sets a scoped variable to a new User instance, and you would call a custom tag or use EL to invoke the UserIO method. The result is cleaner markup and easier maintenance.

Deploying the application to Tomcat involves placing the compiled classes in WEB-INF/classes, copying the JSP and any supporting HTML files into the web root, and ensuring that WEB-INF/etc/UserEmail.txt is writable by the Tomcat process. Once the application is deployed, you can navigate to the JSP in a browser, submit the form, and observe the data appearing in the confirmation page as well as being appended to the text file. If you refresh the page or submit another entry, the file grows, proving that the integration between JSP and Java classes works as intended.

Through these steps - defining clean Java classes, compiling and deploying them, importing them into the JSP, and wiring the data flow - you achieve a modular, maintainable web application that keeps business logic out of the view layer. This approach scales well: as your application grows, you can add more business classes, move persistence to a database, or replace scriptlets with tag libraries, all while keeping the JSP focused on rendering.