Will Java finally become a good language for learning programming? - JVM Weekly vol. 126

1. Will Java finally become a good language for learning programming?

Java is a popular programming language for large, complex applications, but it is also commonly used as a first language for beginners – for example, in a school or college environment. These worlds are inherently challenging to reconcile – the language’s features, designed for large services, can overwhelm new students. So while I myself had a course in Java in college, in such a high school I was taught the basics of programming on the much easier-to-understand Pascal (does anyone still remember this language?).

JDK developers recently stated as part of the Paving on the on-ramp publication ((which you’ve had the opportunity to read about in the past), that the entry threshold for beginners should be lowered. Now the promises are materializing in the first of the JEPs described today – JEP draft: Anonymous Main Classes and Enhanced Main Methods (Preview). Even if you are not a “freshman,” you too will find something of interest in it for yourself

Because you too may someday find yourself in the above situation.

This is because the JDK developers have decided to simplify the syntax of the language for people who use Java as their first programming language. This will be achieved through several consequential steps. The first is to change the so-called “launch protocol” for Java. Let’s take a look at this all-too-familiar piece of code:

public class HelloWorld { 
    public static void main(String[] args) { 
        System.out.println("Hello, World!");
    }
}

The whole thing has a great deal of redundant syntax – static, void, array argument. I suspect that a great many of your applications, for example, have never read arguments from the command line, in which case String[] args is just unnecessary noise. Such concepts should be able to be conveyed to novices when they are realistically needed – but not before. However, this is where the mentioned Launch Protocol comes in – that is, a set of rules defining what a function that is an entry point to a program must look like. This one is to be greatly simplified and allow the whole thing to be boiled down even to the following form:

class HelloWorld { 
    void main() { 
        System.out.println("Hello, World!");
    }
}

Of course, in order to maintain an appropriate level of backward compatibility, the whole thing was fortified by a set of rules defining which variant is selected as the main one main. But for such, I already refer you to the original JEP.

Now it’s time to address the second part of the new Draft’s name. Since the “main” code itself has been simplified, it would be worthwhile to deal with the second part of the boilerplate as well:

class HelloWorld { 
    (...)
}

Today, to get started with Java at all, it is necessary to understand the concept of classes, which is sometimes very difficult to explain to novices. Therefore, the developers of JDK have decided that this element should be slimmed down as well, and intend to introduce anonymous classes – that is, to make it possible to skip the above code fragment and write in a more “scripted” way.

This makes writing a program using an anonymous main class more focused on what the program actually does, without introducing redundant, unnecessary concepts. Each anonymous main class supports the same modifiers as regular “named” classes, has a default, argumentless constructor, and can have a static initializer. An anonymous main class must also have a main function.

In practice, it boils down to the fact that the code:

String greeting() { return "Hello, World!"; }

void main() {
    System.out.println(greeting());
}

is wrapped in:

new Object() {
    String greeting() { return "Hello, World!"; }

    void main() {
         System.out.println(greeting());
    }
}.main()

However, there is a bit of simplification in the above – the original JEP contains many interesting details.

Interestingly – when it was first published, the whole thing was called JEP Draft: Implicit Classes and Enhanced Main Methods. Probably to many Scala programmers the name sounds all too familiar, plus the term describes a completely different concept. As a result, it’s a good thing they decided to change it – we have too many name conflicts between programming languages in the industry anyway.

Sources

2. JDK says goodbye to the x86-32 processor architecture

It is said that there is nothing more pleasant than removing code that is no longer needed. It seems to me that by maintaining a project like the JDK, one can take a step closer to nirvana – and that is by removing entire runtime environments.

Indeed, as reported in the JEP draft: Deprecate the Windows x86-32 Port, JDK developers are going to remove the 32-bit version of the JDK for the Windows operating system. Several factors have contributed to such a step, like the fact that Microsoft has finally stopped releasing new versions of 32-bit operating systems, and the last of them (Windows 10) will lose developer support in the second half of 2025. Much more interesting here, however, are the practical motives – for it turns out from the JEP that the Virtual Threads implementation is not compatible with 32-bit processors.

Probably the above was known for a long time, and only for me it took me by surprise.

Also, soon those wishing to build an application using the JDK on abandoned systems will be greeted by the following message.

configure: error: The Windows x86-32 port is deprecated and may be removed in a future release.

Well, 32-bit processors are now a thing of the past – the last supported version will remain that for the arm32 architecture. If for some reason it is crucial for you to maintain support for Windows x86-32, the JDK developers are leaving an option – they will withdraw from the above JEP, if they find an entity determined to migrate virtual threads to 32-bit, but also to continue to maintain the entire port as well. I say right away that there is nothing to count on Microsoft – it was they themselves who proposed this JEP.

According to Ned Stark’s rules

Sources

3. JDK 20 lived to see changes in its list of JEPs

As we are already in the world of JEPs, there is a very unusual situation. After all, JDK 20 – due for release as early as March – has been in the Rampdown phase since last December. This means that, by design, we should no longer expect any news to appear in it. Last week, however, a new JEP was added by surprise – 438: Vector API (Fifth Incubator).

I reassure all those who fear for the stability of JDK 20 in the face of such a late extension – the fifth incubation of the Vector API has been accidentally omitted, because it is another version of the proposal release, bringing no new changes to the API and source code compared to JEP 426: Vector API (Fourth Incubator), so there is no risk of any unforeseen regressions and the change is formal. The entire situation is explained in an email by Mark Reinhold.

It can be said that the Release Train left and did not pick up a passenger.

However, there is an interesting new piece of information in the JEP itself – in fact, we will be waiting for the Vector API itself for a long time to come, as no Preview version is expected before Project Valhalla is stabilized. The long-term goal of the Vector API is to take advantage of Valhalla’s enhancements, especially Value Classes, which have no identity. The Vector API will therefore be incubated for multiple releases until the necessary Project Valhalla features become available as Preview. Once made available, the Vector API will adapt and also only then make it to Preview itself. It will be interesting to see how many more incubations await us as a result.

And as I’ve already spent a few paragraphs forcing you to read the details of the JEP, for which we’re still waiting, as a reward I’ll toss you two very good, fresh publications summarizing both the current state of Valhalla and the ways and uses of the Vector API. For those interested in the topic, I refer you to the publications Project Valhalla: A look inside Java’s epic refactor and Accelerating vector operations on the JVM using the new jdk.incubator.vector module, respectively. Both topics are everchanging and tend to be overdone, these texts will help you better organize your knowledge.

And since we were talking about JDK 20, I’ll mention at the very end the release that will accompany it. This is because the first test edition of GraalVM CE 23.0.0 has been released, which builds on the upcoming JDK version. We also learned that GraalVM 23.0 will include support for ZGC. This will make it possible to use the aforementioned Garbage Collector when Graal is used as a JIT compiler. To make things not too sweet – ZGC will still not be supported in the case of Native Image. These, however, will also see improvements – as they are to be available out-of-the-box, without the need to install additional dependencies.

Will Java finally become a good language for learning programming? – JVM Weekly vol. 126

1. Will Java finally become a good language for learning programming?

Sources

2. JDK says goodbye to the x86-32 processor architecture

Sources

3. JDK 20 lived to see changes in its list of JEPs

Sources

Discover more great content!