#25 Deconstruction and functional transformation of immutable objects
Extending JUnit 5. Improve build times in Spring Test. Graceful-Shutdown, Readiness and Liveness probe. How GPT-3 Works - Visualizations and Animations.
Welcome to the twenty-fifth edition!
We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.
— David Parnas 1971
We are close to the release of JDK version 15 and many new events arise around version 16:
On September 4th the Mercurial repository for JDK will become read-only and the Git repository located in GitHub will become read-write on Monday 7th September.
Pattern matching for `instanceof` and Records will be released as final in JDK 16.
JEP 338: Vector API has been proposed to target JDK 16 (incubation)
Deconstruction and functional transformation of immutable objects
In the latest edition, we talked about the New Future for Java. In this edition, we are going to see Brian Goetz's dreams.
Brian has published two documents in the new JDK GitHub thinking out loud about how can Java evolve from Records feature, and future paths.
In “Deconstruction patterns for records and classes” he presents the “deconstructor” concept. Starting from JEP 375 (Pattern Matching for instanceof) he goes one step further to declare a variable (
foo instanceof Point p
) and proposes the option of declaring the members of the class:foo instanceof Point(var x, var y)
. He then explores the possibility of generalizing the idea to any Class, not just for Records.In “Functional transformation of immutable objects” Grian evolves the deconstructor and invents the reconstruction expression: given a Record, create a block that has implicitly declared all its members as variables (using the deconstructor), modify their values and automatically create a new instance using the modified values (via the constructor):
Point shiftedPoint = p with { x = 3; }
As Brian tells it, it doesn't seem to be very complex to implement. We don't know how many resources they have or what priority these kinds of changes have, but it’s interesting to know that they are working on it and that they open up to debate in an early stage.
Are such important language changes limited to the Oracle team? or can language improvements really be driven and led by teams in other organizations?
Extending JUnit 5
JUnit 4 evolved to its limits and had some problems that conditioned the way we wrote our tests. Mainly in Integration Tests, where you have to use some utilities that help in the setup of the test. Because you have only one extension point (@RunWith
) you can only apply one utility.
JUnit 5 started from scratch and rewrote the library, avoiding those problems. The proposed mechanism is the Custom Extensions.
You have a complete guide in the JUnit 5 documentation, but as an introduction about the functionality, Michael Scharhag has written an article: “Extending JUnit 5”.
Custom Extensions allows us to configure the Setup of tests in an alternative way and it’s not limited to framework utilities.
We can also externalize a cross-cutting configuration code to a shared location and simplify our test, making them more expressive.
Improve build times in Spring Test
I have to confess, I have a problem with the Spring Tests: they are very expensive to build and take a long time to run. Probably because I'm not writing them properly.
Philip Riecks had the same problem and decided to investigate and learn how Spring Test works and how the Spring context is created and cached.
Fortunately, he has compiled and written in an article his conclusions: “Improve build times with Context Caching from Spring Test”.
The execution time of the tests is very important, and we must keep it low to avoid being lazy to execute them because they take too long. The test code and the production code are equally important, and we must care for it equally.
Spring is a complex framework and its complexities are reflected in the tests. My advice is to stay as far away from him as possible in the tests, minimizing the coupling to him in your business logic.
Graceful-Shutdown, Readiness and Liveness probe
The cloud is a fact, and our companies serve our customers 24x7. A service failure is not acceptable.
How do you reach a high level of availability? Technology can help you, but tools become magic if you don’t know why you must apply it. To formalize the principles and reasons behind some good practices, the Heroku team created “The Twelve-Factor App” methodology.
In the 9th factor (Disposability) they say that you must “Maximize robustness with fast startup and graceful shutdown”. To support this, Kubernetes proposes you to create some endpoints that signal when the application is ready: Liveness and Readiness probes.
You can implement this mechanism manually or delegate it to your application framework. At Clarity, we have implemented it manually because we are still in Spring Boot 2.1, but Spring Boot 2.3 has implemented some support for it, thanks to the existing actuator library.
To learn more about the functionality I recommend the following article: “Configuring Graceful-Shutdown, Readiness and Liveness Probe in Spring Boot 2.3.0”
How GPT-3 Works
The latest technological marvel brought to us by the area of Artificial Intelligence is GPT-3, which is capable to write meaningful things about any topic and chat with you, being close to passing the Turing Test.
Software is eating the world and no job is safe, including development. Even though it wasn't their goal GPT-3 has learned to code: given a description in natural language can write React, Python, SQL, Git commands, or even design (I couldn’t find a sample with Java… )
Will GPT-3 replace us? I don't think so. GPT-3, or a specialized versions of it around programming, will make us more productive, performing the most tedious and repetitive tasks (until we reach the Artificial General Intelligence).
Nobody is worried because the IDE can write/suggest 70% of your code, because static analysis tools can find our bugs, or because NoCode tools allow us to launch a PoC/MVP.
Eventually, someone will have to describe the functionality, and since human language is ambiguous someone will have to describe it accurately.
The algorithm can replicate things that look like things it has already seen, but it cannot come up with new ideas.
As an introduction to GPT-3 I, recommend you read this article: “How GPT3 Works - Visualizations and Animations”
GPT-3 will not be a mere anecdote. OpenAI and other big corporations will evolve it and create new products that will affect everyone in unexpected ways. More than ever we must evolve and seek our differentiating factors if we do not want to be disposable.