Java Fundamentals Java OOPs Exception Handling Generics Lambda Expressions Collection Framework Java8 Streams Multithreading and Concurrency Design Patterns Java11 Features Java17 Features

Additional Java EE Modules Removed

By / 27 April 2025 / 5 minutes of reading

Additional Java EE Modules Removed from Java 11

Java 11 continued the trend of removing Java EE (Enterprise Edition) modules from the JDK, which started in earlier versions (like Java 9 and Java 10). This was a significant shift in Java’s ecosystem as it marked the end of the official inclusion of Java EE technologies in the JDK distribution. These modules were removed as part of Oracle’s efforts to streamline Java and encourage the community to migrate to the Jakarta EE project.

The Java EE modules were initially part of the JDK to provide enterprise-level services such as web services, messaging, and distributed applications. However, over time, Java EE became a separate specification maintained by the Eclipse Foundation under the new name Jakarta EE. The goal was to make the platform more flexible and allow for independent innovation, while still maintaining backward compatibility.

Here’s a summary of the additional Java EE modules that were removed from the JDK in Java 11:

1. javax.xml.ws (Java API for XML Web Services)

  • Module Removed: java.xml.ws

  • The Java API for XML Web Services (JAX-WS) was deprecated in Java 9 and removed in Java 11. JAX-WS was used to build web services in Java and was part of Java EE for handling XML-based web services.

  • Replacement: Developers are encouraged to migrate to JAX-RS (Java API for RESTful Web Services) or use Jakarta EE (specifically Jakarta Web Services) for modern web service development.

  • Impact: If you’re using SOAP-based services, the removal of JAX-WS means you’ll need to look for third-party libraries or migrate to Jakarta EE’s web services package.

2. javax.activation (JavaBeans Activation Framework)

  • Module Removed: javax.activation

  • The JavaBeans Activation Framework (JAF), used for handling different data types in Java (such as MIME types), was also removed. JAF had a limited use, primarily in email applications and some web service functionality.

  • Replacement: It is now a part of Jakarta Activation under the Jakarta EE umbrella.

  • Impact: Applications relying on JAF for processing MIME types must migrate to the Jakarta Activation API.

3. javax.transaction (Java Transaction API)

  • Module Removed: javax.transaction

  • The Java Transaction API (JTA) was part of Java EE for handling transactions across multiple resources, and it has also been removed.

  • Replacement: The Jakarta Transactions API is the replacement, available in the Jakarta EE project.

  • Impact: If your applications use JTA to manage distributed transactions, you will need to migrate to Jakarta Transactions.

4. javax.jms (Java Message Service)

  • Module Removed: javax.jms

  • The Java Message Service (JMS) is a part of Java EE for handling messaging and queuing, typically used for asynchronous communication between different components.

  • Replacement: Developers should migrate to Jakarta Messaging (the new name under Jakarta EE) or other modern messaging frameworks like Apache Kafka or ActiveMQ.

  • Impact: If you’re building message-driven applications, switching to Jakarta Messaging or an alternative is required.

5. javax.servlet (Servlet API)

  • Module Removed: javax.servlet

  • The Servlet API, which has been central to Java web applications, is another Java EE technology removed in Java 11. Servlets provide the foundation for building web applications, handling HTTP requests and responses.

  • Replacement: Developers should move to Jakarta Servlet, which is now part of Jakarta EE. The Jakarta Servlet 5.0 specification is the modern version.

  • Impact: Web applications that use Servlets will need to transition to Jakarta Servlet for continued support and development.

6. javax.el (Expression Language)

  • Module Removed: javax.el

  • The Expression Language (EL) was used to support dynamic expression evaluation in JSPs (JavaServer Pages) and Java EE technologies.

  • Replacement: The replacement is Jakarta Expression Language, part of Jakarta EE.

  • Impact: If your project depends on JSPs or JSF (JavaServer Faces), you will need to update your dependencies to Jakarta EL.

7. javax.persistence (Java Persistence API)

  • Module Removed: javax.persistence

  • The Java Persistence API (JPA), which is used for object-relational mapping (ORM) and database interaction, was also removed.

  • Replacement: The Jakarta Persistence API is now the recommended alternative, part of Jakarta EE.

  • Impact: Applications using JPA for ORM will need to switch to Jakarta Persistence to stay compatible with newer versions.

8. javax.validation (Java Bean Validation)

  • Module Removed: javax.validation

  • The Java Bean Validation API, used for validating JavaBeans in Java EE, was removed in Java 11.

  • Replacement: Jakarta Bean Validation now serves as the modern, Jakarta EE-based solution for validation.

  • Impact: Applications that use validation annotations like @NotNull or @Size will need to migrate to Jakarta Bean Validation.

9. javax.activation (Activation Framework)

  • Module Removed: javax.activation

  • This module was used to handle MIME types and data activation. It had limited use but was removed in Java 11.

  • Replacement: Jakarta Activation is the replacement in the Jakarta EE ecosystem.

  • Impact: Developers using this feature will need to switch to Jakarta Activation.

What Does This Mean for Java Developers?

  1. Migration to Jakarta EE: Java EE technologies were officially moved to the Jakarta EE project under the Eclipse Foundation. This means that any enterprise-level application relying on Java EE features must migrate to Jakarta EE. For example, instead of javax.persistence, developers now need to use jakarta.persistence. This shift in naming conventions (from javax.* to jakarta.*) is significant and developers must ensure that their code and dependencies are updated accordingly.

  2. Third-Party Libraries: If you’re using third-party libraries or frameworks that depend on these Java EE modules, you’ll need to update them to use the Jakarta EE versions of the APIs. Fortunately, many libraries have already made the switch.

  3. Transition Period: Since Java 11 only removes these features, they remain deprecated and available in earlier versions of Java. However, Java 11 is signaling that you should begin migrating away from them to avoid potential issues in future versions.

  4. Reduced JDK Size: The removal of Java EE modules has contributed to reducing the size of the JDK, which now focuses more on the core Java runtime and standard libraries, leaving enterprise-level functionality to external libraries and frameworks.

Java 11’s removal of Java EE modules is a major shift in the Java ecosystem, pushing developers to move to Jakarta EE for their enterprise application development needs. By removing modules like javax.servlet, javax.persistence, and javax.jms, Java 11 signals that it is no longer the go-to platform for enterprise-level functionality. Moving to Jakarta EE will be essential for continued support and development, but this also opens up new opportunities for modernizing Java enterprise applications, reducing the overall complexity, and keeping Java development fresh and aligned with contemporary frameworks and technologies.

Related Posts

Scroll to Top