Chapter 68. Really Looking Under the Hood

Rafael Benevides

Java is a complete platform and should be treated that way. In my Java development career, I’ve met hundreds of developers who are deeply familiar with the language’s syntax. They understand lambdas and streams and know every API from String to nio off the top of their heads. But understanding the following would make them more complete professionals:

Garbage collection algorithms
The JVM GC has improved a lot since its first versions. The JVM’s ergonomics allow it to automatically adjust to have optimal parameters for the detected environment. A good understanding of what is going on can sometimes improve the JVM performance further.
JVM profilers
JVM tuning is not a guessing game. You should understand how the application is behaving before you make any changes. Knowing how to connect and interpret the profiler’s data will help you tune the JVM for better performance, find memory leaks, or understand why a method is taking so long to execute.

Cloud-native applications make it clear that code can be executed on multiple machines across a network over different operating systems. Knowing the following can help Java pros develop a resilient and portable application:

Character encoding
Different OSs can work with different character encodings. Understanding what they are and how to set them up can prevent your application from presenting weird characters.
TCP/IP networking
Cloud-native applications are distributed systems. In a world of cloud, internet, and network, understanding how to route tables, latency, firewalls, and everything related to TCP/IP networking is important, especially when things don’t work as expected.
HTTP protocol
In a world where the browser is the client, understanding how HTTP 1.1 and 2.0 work can help you design your application better. Knowing what happens when you store your data in an HTTP session, especially in a multiclustered environment, can be quite helpful.

It’s even good to know what frameworks are doing under the hood. Here we can take object relational mapping (ORM) frameworks like JPA and Hibernate as examples:

Enable SQL output during development
With SQL output enabled, you can see what commands are being sent to the database before finding out an odd SQL call is behaving badly.
Query fetch size
Most JPA/Hibernate implementations have a default fetch size of one (1). That means that if your query brings 1,000 entities from the database, 1,000 SQL commands will be executed to populate those entities. You can tune the fetch size to reduce the number of SQL instructions performed. You can identify this problem by having the SQL output enabled (see previous item).
One-to-many and many-to-one relationships
Although one-to-many relationships are lazy loaded by default, some developers make the mistake of changing the relationship to eager load the entities or manually initialize them before returning the collection of entities. Be careful about doing that because each eager-loaded entity can also create the many-to-one relationship, causing you to fetch almost every table/entity from the database. Enabling SQL output can help you to identify this problem as well (again, see first item).

In short, don’t let yourself be controlled—be in control!

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.140.242.165