#8 Pre-introduction to Project Loom
Java Objects Inside Out. Spring dependencies in Gradle can be tricky. How Java & Scala are Imitating Functional Languages
Welcome to the eighth Dukesletter edition!
In the last edition, I recommended an awesome talk from Pedro Palao about the state of the art of garbage collectors, but in the recording the slides can not be seen completely. I have requested him the slides and he has authorized me to publish it.
The seventh edition was delivered to 428 persons and reached 536 views.
1.- Everything you should know before reading about Project Loom
When Java was released, its creators decided to abstract operative system threads and provide a set of concurrency primitives and a clear memory model.
Java allowed developing multithread applications easily. Compared to locks, semaphores and mutexes that I studied in Operative System courses, programming in Java a concurrent application and servers were simple.
But software is eating the world, and applications are becoming much more functionally complex every day, with more users, more interactions, and data that must be crunched as fast as possible.
In Java, to process more data with the same resources we must make our application even more complex, making it more difficult to code, read and debug. Another option is to change the paradigm and change the way we execute code, forgetting the threads, and adopting other ideas existing in other platforms.
One of these paradigms is Fibers, which are much more lightweight than kernel threads in terms of memory footprint, and the overhead of task-switching among them is close to zero. But to understand why the JDK team is building the Project Loom we must first learn how threading, concurrency or asynchrony works.
Arnaud Bos has written a series of 3 articles talking about these problems:
Finding good introduction level articles on concurrent programming is difficult because every post assumes some prior knowledge. You can quickly find yourself into dark corners of the Web where people talk about lock-free concurrency while you’re absolutely not ready for this!
Before introducing new articles about Project Loom, I invite you to read his articles:
Part 0 - Rationale
Part 1 - It’s all about Scheduling
Part 2 - Blocking code
Part 3 - Asynchronous code
2.- Java Objects Inside Out
One of my favorite JVM hackers is Aleksey Shipilёv. He writes a lot of articles about performance in the JVM, and he is the owner of the JEP about current Shenandoah GC development.
Before reading his latest article I recommend you to read about JOL tool. Do you know how much memory consumes a single object instance? Taking into consideration headers, primitive fields, objects references, inheritance and paddings, memory model…
In the home page of JOL project you can find enough information about it. Play with some of your classes!
Then you can continue with Aleksey's latest article: Java Objects Inside Out, where different JOL’s concepts are explained in more detail.
The article goes into some serious JVM details. It is very interesting to see how it works internally: headers with needed information for the GC and Locks Management, compressed references, object alignment, field alignment and packing.
From the Java (developer) perspective, knowing about object internals allows hiding fields in object alignment shadow, in field alignment gaps, without exploding the apparent instance size. On the other hand, adding just a single little field may baloon the instance size up considerable, and explaining why that happened inevitably involves reasoning about finer Object structure.
3.- Spring dependencies in Gradle can be tricky
Spring and Spring Boot are great tools, they solve a lot of problems and make our lives easier. But when your codebase grows and you get out of the happy path, this magic goes against you.
At Clarity, we use Spring Boot with Gradle, with a multiproject and multimodule monorepo, with dependencies from one project to other project modules, and it is a nightmare. Which version of each library is used in each module? Are you using Spring Dependency Management Plugin correctly?
gradle dependencies
command can help you to get the snapshot of your dependency tree, but will not help you to understand how do you arrived to it.
The following article helps you to understand better how gradle dependencies works, combined with Spring Dependency Management Plugin and BOMs: “Spring dependencies in Gradle can be tricky”.
I’m still trying to put order in our dependency management, don't give up!!
5.- How Java & Scala are Imitating Functional Languages
Java Language is not perfect and is improving day by day, evolving and adding new ideas from different paradigms like functional programming.
The following talk tries to map different concepts from purely functional languages to Java (and scala) features. Spoiler: Java can not map all features and will never do.
But within its limitations, we can take multiple ideas to make our code better, and probably someday move to a better language and live better: