The Java EE API is built around conventions and design principles that are present throughout the whole set of standards. Software engineers will find familiar API patterns and approaches while developing applications. Java EE aims to maintain consistent API usage.

For applications that focus on business use cases first, the most important principle of the technology is not getting in the way. As mentioned earlier, engineers should be able to focus on solving business problems, not spending the majority of their time dealing with technology or framework concerns. Ideally, the domain logic is implemented using plain Java and enhanced with annotations and aspects that enable enterprise environments without affecting or obfuscating the domain code. This implies that the technology doesn't need much engineer attention by enforcing overly complex constraints. In the past, J2EE required many of these overly-complex solutions. Managed beans as well as persistent beans needed to implement interfaces or extend base classes. This obfuscates the domain logic and complicates testability.

In the age of Java EE, the domain logic is implemented in plain Java classes annotated with annotations that tell the container runtime how to apply the enterprise concerns. Clean code practices often suggest writing code for delectability, not reusability. Java EE supports this approach. If for some reason the technology needs to be replaced and the domain logic extracted, this is possible by simply removing the corresponding annotations.

As we will see in Chapter 7, Testing the programming approach highly supports testability, since for the developers, the majority of Java EE specifics are not more than annotations.

A design principle that is existent throughout the whole API is inversion of control (IoC), in other words, don't call us, we'll call you. We see this especially in application boundaries such as JAX-RS resources. The resource methods are defined by annotation Java methods that are later invoked by the container in the correct context. The same holds true for dependency injection that needs to resolve producers or include cross-cutting concerns such as interceptors. Application developers can focus on implementing the logic and defining relationships and leave the actual plumbing to the container. Another, not that obvious example, is declaring the mapping of Java objects to JSON and back via JSON-B annotations. The objects are mapped implicitly in a declarative approach, not necessarily in an explicit, programmatic way.

Another principle that enables engineers to use the technology in a productive way is convention over configuration. By default, Java EE defines specific behavior that matches the majority of use cases. If that is not sufficient or doesn't match the requirements, behavior can be overridden, often at several levels.

There are countless examples of convention over configuration. JAX-RS resource methods mapping Java functionality into HTTP responses is one such method. If JAX-RS's default behavior regarding responses is not adequate, the Response return type can be used. Another example is the specification of managed beans that is usually realized using annotations. To override this behavior, the beans.xml XML descriptor can be used. The welcoming aspect for developers is that in a modern Java EE world, enterprise applications are developed in a pragmatic and highly productive way that does not usually require at lot of XML usage like in the past.

In terms of developer productivity, another important design principle of Java EE is that the platform requires the container to integrate the different standards. As soon as containers support a specific set of APIs, which is the case if the whole Java EE API is supported, it is also required that implementations of the APIs enable straightforward integration of other APIs. A good example is that JAX-RS resources are able to use JSON-B mapping and Bean Validation without explicit configuration other than annotations. In previous examples, we saw how functionalities that are defined in separate standards can be used together without additional effort required. This is also one of the biggest advantages of the Java EE platform. The umbrella specification ensures that the specific standards play well together. Developers can rely on certain features and implementation being provided by the application server.