Is Java EE the Most Lightweight Enterprise Framework?
- January 22, 2018
- Posted by: admin
- Categories: Java, Uncategorized
A long time ago J2EE and, especially, application servers were considered to be too bloated and “heavyweight.” It could be quite tedious and discouraging for developers to use that technology for developing applications. But since the name of the J2EE framework changed to Java EE, that assumption is not true anymore. How does Java EE compare to other enterprise frameworks and what criteria makes a framework lightweight?
When choosing a technology, one of the most important aspects to consider is the developers’ productivity during the development process. Engineers should spend as much time as possible implementing use cases and revenue-generating features, because this is what will move a company towards its goals.The chosen technology and methods should minimize the time developers spend waiting for builds, tests, and deployments; configuring applications; implementing plumbing that is not relevant for business use cases; and configuring the build environment and the external dependencies. But the majority of available technologies do not do this.
- Integration of Specifications:
The specific APIs within the Java EE umbrella—such as Contexts and Dependency Injection (CDI), JAX-RS, JSON Processing (JSR 353), and Bean Validation—work together really well and are meant to be combined with each other seamlessly. Best of all, CDI is used as a “glue” between components of an application. The specification contains wording such as “If the container does support specification A and B, then A has to integrate and work well with B seamlessly.” - Convention-over-Configuration Driven Development:
Because of the convention-over-configuration driven approaches of Java EE, most real-world applications don’t need a lot of configuration. The days of cumbersome XML descriptors are over. For a simple Java EE application, you don’t need a single XML file. Thanks to declarative annotations, a simple annotated plain old Java object (POJO) handles HTTP requests (@Path), or serves as an Enterprise JavaBeans (EJB) bean (@Stateless), respectively—including transactions, monitoring, or interceptors. In the past, these approaches have proven themselves very well in various frameworks and have been standardized in Java EE. XML descriptors can still be used for deployment-time configuration if there is a need for this, but convention-over-configuration helps maximize developer productivity.
- Thin Deployment Artifacts:
Due to the fact that the application server knows about the Java EE API, that API doesn’t have to be included in the deployment artifact. Only the business logic is included—with a minimum of glue code and cross-cutting-concerns. Therefore these kilobyte-sized artifacts make it possible to have very short build times, because the build process doesn’t have to copy a lot of things. This can make a difference of several seconds on each and every build. If you sum up all that extra time that is spent by developers and the continuous integration (CI) server, it makes quite a difference. The more often the project is being built—and this is especially true for continuous delivery (CD) scenarios—the bigger that impact is. - Modern Application Servers:
J2EE application servers were the embodiment of heavyweight software in terms of start and deployment times, installation sizes, and resource footprints. But in the new world of Java EE, this isn’t true anymore. All modern Java EE 7 application servers, such as WildFly, Payara, WebSphere Liberty, Profile and TomEE, start and deploy in a few seconds. Due to internal, comprehensive modularity, they’re able to load only needed components and deploy the thin application artifacts as quickly as possible.
Contact us at one of our office nearest to you or submit a business inquiry online.
