We have seen how Java EE enables all this. The platform supports focusing on business demands by enabling developers to write code without setting too many constraints. Use cases can be designed and implemented by following the domain's demands first.

The technology itself does not want attention. In the majority of cases, it's sufficient to annotate business logic which leads the application container to add the required technical necessities. The approaches of Java EE standards, such as JAX-RS, JPA, or JSON-B, accomplish the required technical integration with minimum effort required.

The Java EE platform especially enables engineers to seamlessly integrate multiple standards without configuration work. The JSR specifications that are written with the principles of Java EE in mind, make this possible.

Modern Java EE has to be seen differently to how it was in the old days of J2EE. In fact, the programming model and runtimes have little to do with J2EE.

With the backwards-compatible nature of the platform, outdated approaches are still possible, but the technology has advanced a lot since then. Programming models and design patterns have been revisited and vastly simplified. In particular, the restrictions of past patterns in implementing hierarchies of technology-motivated interfaces, and superclasses, are gone. Developers are able to focus on business domains, not on the technology.

The nature of the Java EE standards allows companies to realize vendor-independent applications. This avoids vendor lock-in on the technology-side. Developers are also not exclusively trained for vendor-specific technologies. We have seen quite a few cases of teams that were solely familiar with vendors that became obsolete.

Java EE technology is not only used on the server-side. Standards such as JAX-RS, JSON-P, or CDI provide valuable benefits for Java SE applications as well. It makes sense to realize certain functionalities, such as HTTP clients, with standards technology that developers are familiar with.