Stop repeating the "ponderous"
Posted by: Sebastian Daschner
Original: https://blog.sebastian-daschner.com/entries/stop_saying_heavyweight (April 09, 2016)
Translation: Semen Soldatenko
When developing corporate Java applications, one has to choose - to use Java EE or some other âlightweightâ framework. But what makes a corporate framework lightweight?
We, as developers, basically have to take care of the development process. Our time is precious (and expensive) and the less time we spend on overhead, the better.
This time basically consists of the time for compiling, deploying, and testing the application â locally or in a specific environment. In order for the full circle time to be as short as possible, the compilation should not drag on for more than a few seconds. Yes, seconds.
')
Using Java EE has a great advantage in that the developer can rely on a standard that allows you to develop based on APIs â basically just interfaces and annotations â while the actual implementation of the framework is not included in the application. The Java EE dependency itself is âdeliveredâ by the application server, which means that it is required only for compilation, and is not included in the installation package. This has a side effect which is that the war file basically remains empty - it contains only the class files of your application. All the rest should be provided by the Java EE implementation.
As long as you remain skinny and minimalistic, which means using only the Java EE (7) API, and not third-party dependencies - unless there is a real need for your business cases - you can achieve a compile time within a few seconds. The main reasons for the slow build or in slow (integration) tests, or in large installation packages, respectively, requiring a lot of things to copy.
A typical simple Java EE war file is about a few hundred kilobytes in size compared to 50 megabytes or more if you supply an implementation of even a small (well, you know, âlightweightâ) framework with it.
If you consider the application server plus your application, then the result for the case of Java EE will be greater. But: In general, the development process will be faster, since each time during the assembly kilobytes are created. The application server is usually already installed on your development machine â or in any other environment â and the moving parts remain small. As a result, we get a shorter assembly and deployment time both on the developerâs machine and on the Continuous Integration server. And also: When you place your installation packages in a central repository (Nexus or Maven central, etc.), you also save time and traffic.
All modern Java EE 7 application servers (such as Wildfly, TomEE, Glassfish / Payara, WLP) demonstrate a very short time to deploy the application. Within their modular system (such as OSGi), they can download only the necessary components and run the application within a few seconds.
Comparing with another framework (such as Spring) running on Tomcat, the shortest deployment time I've ever measured was at least 15 seconds â for a simple âHello Worldâ application â when measured on the same machine.
In the new world of microservices, it is customary to deliver applications in the form of independent jar containing both the developed application and the framework implementation. In Java EE, this can be achieved using technologies like Wildfly Swarm or TomEE Embedded.
However: As I said above, I do not recommend making your installation packages so large. The biggest problem with this approach is build time, since every time you have to copy a lot of things from A to B. And also: When deploying using containers such as Docker, it becomes unimportant whether your application comes with the server or the server is part of container.
If the container already includes an installed application server, you can save a lot of assembly time (container). In this case, your base image does not change, and you just add your (only a few hundred-kilobyte) application - which is achieved almost without spending time.
Since the days of the old J2EE, there is a myth that âheavyweightâ application servers consume a lot of memory as soon as they start. Adam Bien has published an interesting video showing the actual memory overhead of modern Java EE application servers.
From my point of view, one of the most "lightweight" solutions for enterprise applications is the following:
From the translator:
Semen Soldatenko, CC-BY-NC-SA 4.0
translation of the work Stop saying âheavyweightâ , Sebastian Daschner, CC BY-NC-SA 4.0
Original: https://blog.sebastian-daschner.com/entries/stop_saying_heavyweight (April 09, 2016)
Translation: Semen Soldatenko
When developing corporate Java applications, one has to choose - to use Java EE or some other âlightweightâ framework. But what makes a corporate framework lightweight?
We, as developers, basically have to take care of the development process. Our time is precious (and expensive) and the less time we spend on overhead, the better.
Assembly time
This time basically consists of the time for compiling, deploying, and testing the application â locally or in a specific environment. In order for the full circle time to be as short as possible, the compilation should not drag on for more than a few seconds. Yes, seconds.
')
Using Java EE has a great advantage in that the developer can rely on a standard that allows you to develop based on APIs â basically just interfaces and annotations â while the actual implementation of the framework is not included in the application. The Java EE dependency itself is âdeliveredâ by the application server, which means that it is required only for compilation, and is not included in the installation package. This has a side effect which is that the war file basically remains empty - it contains only the class files of your application. All the rest should be provided by the Java EE implementation.
As long as you remain skinny and minimalistic, which means using only the Java EE (7) API, and not third-party dependencies - unless there is a real need for your business cases - you can achieve a compile time within a few seconds. The main reasons for the slow build or in slow (integration) tests, or in large installation packages, respectively, requiring a lot of things to copy.
Installation package size
A typical simple Java EE war file is about a few hundred kilobytes in size compared to 50 megabytes or more if you supply an implementation of even a small (well, you know, âlightweightâ) framework with it.
If you consider the application server plus your application, then the result for the case of Java EE will be greater. But: In general, the development process will be faster, since each time during the assembly kilobytes are created. The application server is usually already installed on your development machine â or in any other environment â and the moving parts remain small. As a result, we get a shorter assembly and deployment time both on the developerâs machine and on the Continuous Integration server. And also: When you place your installation packages in a central repository (Nexus or Maven central, etc.), you also save time and traffic.
Deployment time
All modern Java EE 7 application servers (such as Wildfly, TomEE, Glassfish / Payara, WLP) demonstrate a very short time to deploy the application. Within their modular system (such as OSGi), they can download only the necessary components and run the application within a few seconds.
Comparing with another framework (such as Spring) running on Tomcat, the shortest deployment time I've ever measured was at least 15 seconds â for a simple âHello Worldâ application â when measured on the same machine.
Thick JARs / Container Integration
In the new world of microservices, it is customary to deliver applications in the form of independent jar containing both the developed application and the framework implementation. In Java EE, this can be achieved using technologies like Wildfly Swarm or TomEE Embedded.
However: As I said above, I do not recommend making your installation packages so large. The biggest problem with this approach is build time, since every time you have to copy a lot of things from A to B. And also: When deploying using containers such as Docker, it becomes unimportant whether your application comes with the server or the server is part of container.
If the container already includes an installed application server, you can save a lot of assembly time (container). In this case, your base image does not change, and you just add your (only a few hundred-kilobyte) application - which is achieved almost without spending time.
Memory consumption
Since the days of the old J2EE, there is a myth that âheavyweightâ application servers consume a lot of memory as soon as they start. Adam Bien has published an interesting video showing the actual memory overhead of modern Java EE application servers.
Conclusion
From my point of view, one of the most "lightweight" solutions for enterprise applications is the following:
- Java EE 7 and Java 8 using only the API provided by the server
- A small war file containing only business logic plus minimal configurations (such as JAX-RS resources or JPA)
- Quick unit tests without test frameworks with an embedded container (just plain JUnit only)
- Deploy containers based on base images containing all the necessary components, with the exception of the application
- The build process is based on Continuous Delivery which deploys the application in containers for each commit
- Automatic system testing of the application deployed to the container (to confirm the high quality of the application without the need for integration testing; at the same time, developers will still receive quick response)
From the translator:
- Enterprise Application - Enterprise Application
- Framework - Framework
- Installation Package - Deployment artifact
- Business case - Business use case
Semen Soldatenko, CC-BY-NC-SA 4.0
translation of the work Stop saying âheavyweightâ , Sebastian Daschner, CC BY-NC-SA 4.0
Source: https://habr.com/ru/post/283290/
All Articles