When you compile or run a Java program that depends on classes from other JAR files or locations, the Java runtime needs to know where to find those classes. The classpath is the list of paths that Java checks for classes and resources. In this guide we’ll explore how to set the classpath in a few different ways—via the java and javac commands, through the CLASSPATH environment variable and by using the -cp / -classpath switch.

What Is the Classpath?

The classpath is a logical list of directories, JAR archives, and other resources that the Java Virtual Machine (JVM) searches for class files. When the JVM loads a class, it looks through the entries in this list in order until it finds the class. If the class isn’t found, a ClassNotFoundException (compile time) or NoClassDefFoundError (runtime) is thrown.

Example of a classpath for a simple project might look like this:

/home/user/project/bin:/home/user/lib/commons-io-2.8.0.jar        

When building RESTful web services, proper exception handling is crucial. Unhandled exceptions can lead to ugly stack traces being sent to the client, exposing internal server details and providing a poor user experience. The JAX-RS specification provides an elegant solution for this: the ExceptionMapper.

In this tutorial, we’ll explore how to use Jersey’s implementation of ExceptionMapper to create centralized, custom, and consistent error responses for our API. We’ll build a simple Spring Boot application with Jersey to demonstrate the concepts.

What is an ExceptionMapper?

An ExceptionMapper is a JAX-RS component that “maps” a Java exception to a javax.ws.rs.core.Response object. When an exception is thrown from a JAX-RS resource method, the framework checks if there’s a registered ExceptionMapper for that specific exception type (or any of its superclasses).

If a mapper is found, its toResponse() method is called. This gives you complete control over the HTTP response sent back to the client, including:

• The HTTP Status Code (e.g., 404 Not Found, 400 Bad Request, 500 Internal Server Error)
• The Response Body (e.g., a structured JSON error object)
• Custom HTTP Headers

Before Java 8, interfaces were a rigid contract. If you had an interface implemented by dozens of classes across multiple projects, adding a new method to that interface was a developer’s nightmare. Why? Because every single implementing class would instantly break, requiring you to manually add an implementation for the new method. This made evolving APIs incredibly difficult and risky.

Enter Java 8 default methods. This powerful feature changed the game by allowing us to add new, fully-implemented methods directly to interfaces without breaking existing code. Let’s dive into how they work, why they’re essential, and how to handle the complexities they introduce.

What Are Default Methods? The “Why” and “How”

A default method is a method in an interface that has a body. It is declared using the default keyword. If a class implements the interface but does not override the default method, it automatically inherits the default implementation.

Think about the java.util.Collection interface. Imagine the chaos if adding the stream() or forEach() method in Java 8 had broken every single List and Set implementation in the world! Default methods were the elegant solution that allowed the Java API to evolve.