9 ARTICLES ABOUT JAVA RECOMMENDED BY TOMASZ BOREK
Check out what the co-leader of SCKRK and GEECON communities has picked to read for all enthusiasts of Java.
We continue the series of must-reads about programming languages and software development recommended by IT experts. You can already check Vitaly Friedman’s picks about Front-end & UX/UI and Cloud & DevOps recommendations from Tomasz Konieczny. Now, it’s time for a deep dive into Java. Our guide is Tomasz Borek. Here's how he describes himself:
Coder from Poland*. Hoping to learn something new every day. Thankful to everybody who helps me while I hop along. Proud of: sckrk.com and geecon.org. Co-leads SCKRK, Polish JUG, Lambda Lounge Kraków. I’m a flawed human, and unafraid to say so. Into: people, software, music, role-playing, honesty, learning. Dislikes: doing unnecessary things, doing “because I can”. * I got it from my parents. They coded and so do I.
Tomasz Borek curates the Java section in Infoshare Monthly Newsletter for developers. In each edition, he recommends noteworthy articles dedicated to developers. For those who haven't subscribed to our newsletter yet, we share some of Tomasz's recommendations with comments not only about Java but also about Jakarta EE 9, Maven security versions, or JEP 358.
Noteworthy articles around Java’s universe picked by Tomasz Borek
Goldie, though oldie, the article by Java Champion Tomasz Nurkiewicz showcases what you can do with CompletableFuture. Tomek will take you on a splendid tour throughout this underappreciated-class APIs, offering code snippets along the way.
Some time ago on Foojay, an interesting series has appeared: “Getting Started with Jakarta EE 9.” I know, I know, microservices and Spring won the race but aren't you curious how things look on the other side, especially given the ownership transfer and the ensuing name-hijinks? The recent installment showcases how to build a REST API with Jakarta EE 9. It nicely demystifies things for those of us still shuddering at the dark ages of the EE specification.
There's a very DevOps-friendly Linux distribution that I’ve found out about NixOS. It uses, nomen omen, an FP language, so also Nix, for config writing. Offering per-project config (compilers, interpreters, tools) while working with Docker to improve minimum images, it has the potential to replace sdkman or asdf. Distro link and Hacker News thread.
There's this unverified quote flying around that your code ratio to dependencies in your project is at 1%. While it may be somewhat different, the discrepancy is real, and pulling Spring or Spring Boot in alone pulls A LOT. Since chain supply attacks are real and all software platforms are under fire (good software taken over or packages named eerily similar to them popping up at Maven Central, Npmjs, browser add-ons, and wherever else), I wanted to let you know about Maven plugin done by RedHat: security versions. Based on the Maven versions’ plugin, they look at your dependencies to tell you if you have something that's vulnerable.
While we still can hear “Lombok covers it” or “do it with Kotlin data classes,” records, among other new features in Java, are making quite the waves. However, what these frequently used comparisons don't take into account is semantics of records. One of the deepest insights into the topic that I've read is by Nicolai Parlog, the author of a book on Java Modules (which I also recommend, I happened to review it when it was in the making). In his post, Nicolai covers (not just touches) the subjects of serialization, boilerplate, semantics, and presents cases where Lombok or Kotlin would work better or worse. By reading his article, you’ll learn in less than 30 minutes a thing or two about records and the intention behind them.
This recommendation is about an article written by Nicolas Frankel, who wrote a book about Integration tests from the trenches (recommended again). Nicolas dedicated an article to a very nice, and sadly not so well-known (as verified by my own inquiries in my circles), API - the teeing stream collector. Those of you who know the GNU/Linux's tee command are probably already nodding their heads, knowing how useful it could be; but just in case you wished to say that “talk is cheap” or “show me the code,” head over to Nicolas’ blog.
Let’s focus on the strong encapsulation that Java 17 offers. It's the next step in the trend that began years ago and even if you don’t use modules, it still may be worth your while. Here is a piece by Java Champion Ben Evans, who talks us through:
- illegal reflective access;
- Java's journey from introducing modules and Jigsaw;
- encapsulation transition that happened between Java 9 and 17;
- the way the new LTS version of Java 17 treats the code that it hasn't so far heeded that warning.
For those among you who are more into technical details, here's the underlying JEP.
InfoWorld editor Paul Krill has authored a not bad (though a bit text-heavy) overview of new features in Java 17. I'd usually add the links to JEPs here, to add technical depth, but Paul very kindly begins each feature description with a relevant link, making this totally pointless on my part. So, you get a nice overview and an explanation, and, if needed, you can go deeper.
On the topic of nulls, I wanted to bring your attention to JEP-358, the one about helpful NPEs, that nicely illuminated how Java 14 and higher offers a better debugging experience and easier tracing of the underlying problem. Kevin Bourrillion (or Kevin B9n as he styles himself due to how people tend to mispronounce his name) has published this very detailed presentation about null-handling. It's an interesting read and while JSpecify mentioned there is very early in the making, it may be going places. Unless the XKCD comic triumphs (hint: don't send them the comic about competing standards :)).
A fresh dose of experts’ picks in the Infoshare newsletter
If you want to be up to date with experts’ recommendations about Java, AI & ML, Cloud & DevOps, Front-end, and IT Leadership, subscribe to our monthly newsletter intended for software developers.
HAVE ANY IDEA FOR CONTENT?
Contact the editorial team at:firstname.lastname@example.org