How to enter the world of Java in 2023? JVM Weekly vol. 121

The year is just gaining momentum, so in today’s issue, I have some longer texts for you, in addition to news, which you may find helpful. There will also be exciting releases (e.g. Mockito 5.0 with big changes).

Article cover

1. A set of tips on how to automate vulnerability detection in your project

Security is a topic as broad as it is often neglected, which ultimately ends in weeping, gnashing of teeth, and sections covering your mistakes in newsletters like this one. That’s why, in early 2023, I wanted to toss you the publication The ultimate guide to Java Security Vulnerabilities (CVE) which is an excellent tutorial on how to work with broad SecOps tools in Java.

And I immediately also sneak the above gold. The glass is always half full!

At the end of last year, Lukasz Myslinski described an ecosystem of tools developers can use to check their “supply chain” of dependencies. There is no shortage of similar texts in the internet – they are often written by the developers of the tools appearing in this article like e.g. snyk.io. However, the advantage of Lukasz’s publication is being strictly java-centric. Many of the tips are simply very easy to use immediately in your project, without additional translation. So I recommend a lecture, especially if you’re soon facing an audit, or an ISO recertification, or want to see if you have any overlooked holes in your repo.

To the above list, I’d also toss in SecHub – an open-source tool, developed by Mercedes and written in Java, that lets you aggregate multiple online security scanners under a common umbrella. I will be watching the development of the project, as what has been shown so far has a lot of potential.


Discover more IT content selected for you
In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

phone newsletter image

2. Native GraalVM images running on RISC-V

This news is a bit minor, but somehow it fits in so nicely with the recent changes to the JDK. That is why I’d like to share with you the fact that Native GraalVM images can be fired up on RISC-V architecture, as announced by Sacha Coppey, who works at Oracle Labs.

RISC-V is not an off-the-shelf processor, but an instruction set architecture based on the philosophy of providing a strictly reduced instruction set computer (RISC). Quoting Wikipedia:

Unlike most ISAs, RISC-V can be freely used for any purpose, allowing anyone to design, manufacture and sell RISC-V chips and software. Although it is not the first open ISA architecture, it is significant because it was designed for modern computerized devices such as massive cloud computing, high-end cell phones and the smallest embedded systems.

From my perspective, the very process that made this kind of operation possible is interesting, as it reminds us of the versatility of the whole GraalVM project. While the GraalVM compiler itself does not allow the creation of binaries for this architecture, Native Images are flexible enough to plug in LLVM – a universal compiler used by a number of different languages. If you are curious about what LLVM is, I recommend the publication What is LLVM? The power behind Swift, Rust, Clang, and more. In my opinion, it is worth at least being aware of its existence – we are talking about one of the most important building blocks of the programming world, which, however, is not known to the broad masses of programmers.

In general, JDK is becoming increasingly exposed to RISC-V, after all, support for these ISA just appeared in JDK 19 last fall.

I’d really like to see some usage statistics.


3. How to become a Java programmer in 2023? There is an article that will help!

I have a feeling that, given the scope of this newsletter, I’m unlikely to have too many Java newbies among my audience (if I’m wrong, please write how you endured the insert about RISC-V support in GraalVM). However, I’m sure many of us have younger friends (though probably not exclusively) who ask how to even get started with all this Java. It happens to me sometimes, and I’ll admit that the answer is not always so obvious. Having some experience already, It’s really hard to outline a coherent, logical path that such a person would follow.

That’s why I’m always very happy to find texts that I can toss out as “first steps.” And just last week, such a publication was published by Gunnar Morling. Getting Started With Java Development in 2023 – An Opinionated Guide landed right at the top of my private ranking of favorite items for newcomers. Its freshness (it has 2023 in its name for a reason) also has an interesting side effect – if you are working on a project that is stuck on Java 8 and some old version of Spring, the publication will allow you to refresh your knowledge and consider what you might have missed.

Therefore, in principle, I recommend at least looking at the whole thing to everyone.


Discover more IT content selected for you
In Vived, you will find articles handpicked by devs. Download the app and read the good stuff!

phone newsletter image

4. Release Radar

And at the very end, some interesting releases from the recent week.

Kotlin 1.8

Yes, I know, I wrote about Kotlin 1.8 just last week as a ghost release, and it, as if out of spite, appeared on the exact same day as my rant. Still, it’s a noteworthy fact, because with the official release we got the standard set of accompanying materials, such as the video introduction to the new version of the language, which as always I highly recommend.

You can find more of my thoughts in the previous edition.

Mockito 5.0

The second of the interesting releases from the beginning of the year is Mockito 5.0. It illustrates that all sorts of migrations to new versions of Java will not always be so seamless.

After all, Mockito is a rather unusual project – as it generates Object Mockups, it repeatedly has to bypass access modifiers that exist in Java. Sometimes they need to use mechanisms such as reflection, and in some cases going even deeper – to JVM internals. The latter, in turn, is not a stable API and – by definition – regularly changes between JDK versions. Sometimes these modifications are transparent for library creators, but it is not always possible. It is also very difficult to support multiple versions of the JDK in parallel, because each version may require a bit different mechanism.

As a result, in Mockito 5.0 it was decided to get rid of support for older JDKs, making JDK 11 the minimum supported version. At the same time, however, developers had to develop a new way of mocking subclasses. It’s because with each successive Java release, due to stronger limitations of access to JDK internals in successive editions, the old solutions became more and more limited. With version 5.0, mockito-inline – a new mechanism – finally became the default solution

The whole situation is close to my heart for two reasons. First, I am (proudly!) a member of the GitHub organization Mockito, having once worked with its developers on their other open-source shipkit. Unfortunately, it has been dead for some time now but still a wonderful experience – if you read it, thank you for the opportunity 🤩. In addition, I myself have historically encountered problems with Mockito internals, which I described in my first ever text on JVM.

Beautiful memories – I have become sentimental in my old age.