When I had heard that finalization is (finally!) marked for removal, I was really happy. Some time in the future it will be gone for good from the JDK, which means less code, higher reliability, tighter security and a tad more performance. Marking something for removal from JDK is an extremely rare event. After all, source compatibility is one of the strongest Java’s points - you can just grab some source code from version X and it’s a really big surprise if it doesn’t compile in verson X+N. What is so bad about the finalization that it had to be marked for removal?
My son is 7½ years old and goes into second grade. We are not native English speakers – as the matter of fact, English is only his third language after Serbian and German. He knows maybe 100 English words, yet he managed to learn and deliberately apply 4 bash commands after just 1 hour of “studying” with me! I wanted to share this story to demonstrate what kids can effortlessly do if we give them just a bit of nudge, even in this time of flashy apps and games. I will reconstruct our “learning” session in the form of dialogue.
In the part 1 we’ve seen how we can use inline snippets in Javadoc and how to control their appearance with regions and highlighting. While such usage should be enough for a lot of use-cases, from time to time we’ll need more power, for example to include snippets with block comments. In such cases, external snippets come to the rescue. Let’s see how to use them!
Ah, good old charsets, who doesn’t like them! With so many variations in operating systems, programming languages, human languages, geographical locations etc. what could possibly go wrong when we try to read from or write to files, sockets, screens and other input-output devices? It turns out, quite a lot. There’s no shortage of developer horror stories caused by wrong or improper encoding of data. While Java 18 doesn’t promise a silver bullet, it makes a step in the right direction because ubiquitous UTF-8 charset will become a default. Let’s see what it means to us developers.
In the part 1 we’ve seen how we can use Simple Web Server (SWS) from the command line during writing or debugging web applications. While such usage should be enough for a lot of use-cases, from time to time we’ll need more control over which HTTP methods, headers, MIME types etc. That’s why in Java 18 there is a possibility to use SWS programmatically, i.e. to embed it into our applications. For that, we can use some existing classes (i.e. pre Java 18) and also some new ones. Let’s see the basic programmatic usage of Simple Web Server (SWS) in action!
A lot of developers work on writing or debugging web applications daily. Sometimes that work involves writing our application’s backend and sometimes consuming other web resources, whether they are APIs or “normal” web pages. Other programming languages recognised the need for having a “quick and dirty” way of serving resources over HTTP(S) protocol during the development. Good people that developed JDK 18 gave us the opportunity to have that in Java too so we don’t have to look at node.js, Python or PHP developers with envy any more when they brag how simple it is to start serving resources in their languages. Let’s see the basic usage of Simple Web Server (SWS) in action!
As Java developers our job is not only to write working code but also to document it properly. Since its beginnings Java provided us with the javadoc tool which generates this documentation from the specially formatted documentation comments we wrote in the source code. In these documentation comments we use various tags to document parameters, return values, exceptions thrown etc. It is often the case that we must include a code snippet to show intended usage of our code. Until Java 18 we relied on the @code tag, perhaps in combination with <pre>…</pre> if we needed multi-line snippets. But now we have a better way and that is by using new @snippet tag. Let’s see its basic usage in action!
As Java developers we often must work with multiple projects at the same time. Even if all projects you develop as a part of your job use the same JDK version, you might still have private projects with a different one, or you simply want to experiment with the new JDK as it’s released. In those cases, using jEnv to assign an appropriate JDK to every project is a life saver. Best of all, it’s very easy to use and it doesn’t require wrangling with the JAVA_HOME environment variable. Let’s quickly see it in action!
Java 18 is currently the latest version of Java. Even though it isn’t a LTS release, it’s worth installing it so we can test new features. In this article I will show you how to install JDK 18 on MacOS and to setup IntelliJ IDEA so you can write Java applications against it.