JEP445 Instance main() methods coming for Java 21 LTS

Java 21 is only a few weeks away from release. One of the changes that I think is the most interesting and I’m surprised that it’s taken this long to be included is JEP445 “Unnamed Classes and Instance main methods”. The goals of this JEP explain precisely the benefit of this change:

“Offer a smooth on-ramp to Java so that educators can introduce programming concepts in a gradual manner.”

“Reduce the ceremony of writing simple programs such as scripts and command-line utilities.”

“Instance main methods” refers to a change to the language requirement that the single entry point to a Java application is the main() method with this exact signature:

public void main(String[] args) {
    ...
}

…which is a lot to unpack to understand how to get started even with the most basic “Hello World” app. To explain this signature to brand new developers learning Java, I usually see the required main signature explained away with “ignore why we need this for now, just accept that you need to define the main method exactly like this for it to work” which doesn’t exactly give much comfort.

JEP445 Instance main methods allows support for much simpler main methods without the required scope, return type and params:

void main() {
...
}

To make it even easier, since this new support now allows you to use an instance method instead of the previously required Class method (static), you can call other instance methods without instantiating the class, and without understanding why you can’t call instance methods from a static method. Prevously you need to instantiate your Class first, before calling instance methods like this:

public class PreJava21App {
    public String getGreeting() {
        return "Hello World!";
    }

    public static void main(String[] args) {
        System.out.println(new PreJava21App().getGreeting());
    }
}

With JEP445 now you can code a simpler main() like this:

public class Java21App {
    public String getGreeting() {
        return "Hello World from Java 21!";
    }

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

The next change on this JEP with Java 21 introduces Unnamed Classes, so now even the Class declaration can be implicit, like this:

    public String getGreeting() {
        return "Hello World from Java 21 with implicit Classes!";
    }

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

Under the covers there’s still a Class, it’s implicitly named the same as the filename, so if you save the above in a file classed Java21App, then you’d run it with ‘java Java21App’.

To enable these features currently (as of OpenJDK build 21-ea+28), you need to pass the ‘–enable-preview’ param. To pass this with gradle, add the following to your build.gradle:

//pass required JVM param for compile time
tasks.withType(JavaCompile) {
    options.compilerArgs += "--enable-preview"
}

//pass required JVM param for runtime
tasks.withType(JavaExec) {
    jvmArgs += '--enable-preview'
}

What tech stack was I working with in May 2003?

Clearing out some stuff in the home office I came across this CD-ROM of tech tools, products and libraries that I was using at work at this time:

  • JBoss – the open source Java EE app server of choice at this time
  • Xerces – Java XML Parsing library (DOM)
  • Amazon WS Kit – not sure what this was, maybe an SDK for AWS?
  • Apache – HTTP web server
  • Caucho Resin – no longer around – if I remember right this was an optimized Servlet runtime
  • EJ Tech Profiler – I think this was a competitor to JProfiler?
  • Homesite – HTML editor
  • IBM WS Kit – SDK for Java XML webservices
  • IntelliJ – still around today. At the time I don’t think it was as popular as Eclipse or Netbeans, but is probably the best. Java IDE around today

Interesting look back at Java versions in use at the time:

  • Java JDK 1.4 (at the time, also called Java 2 after JDK version 1.2, abbreviated as J2SE)
  • Java EE 1.2 and 1.3 – abbreviated to J2EE – the days when J2EE was actually called J2EE before dropping the 2 and just becoming Java EE after Java EE 5 was released in 2006)

Don’t use floats and doubles in Java to represent Money values (or anything where you need exact values)

Float and double types in Java are approximations – they don’t represent exact values. This is by design to allow faster calculations of approximate values at the cost of exact accuracy.

If you are new to Java, at some point you will run into this, or you’ll come across someone else you work with who may tell you to never use floats and doubles to represent Money, but maybe you’re not sure why. The reason is because of how floats and doubles represent approximate values.

If you’ve never come across this before, try this experiment:

float result = 0.01f + 0.01f + 0.01f;

You would expect this calculation to represent 0.03, but if you compare the value of result with 0.03f you’ll find this snippet of code unexpectedly prints false:

if(result == 0.03f){
    System.out.println("true");
}
else{
    System.out.println("false");
}

To represent accurate floating point values use BigDecimal. Alternatively, money values can be represented as an integer value in cents or pennies (for example) to avoid the approximation issues.

tldr; Don’t use floats and doubles to represent money values in Java.

Java local variable vs class field initialization and default values

This is a common error when starting out with Java:

DefaultValues.java:5: error: variable example might not have been initialized
        System.out.println(example);

In Java, Class instance properties are initialized to default values if not explicitly defined with an initial value. For local variables however (e.g. variables local within method or a block scope), default values are not automatically assigned, meaning that you must explicitly initialize them otherwise you’ll see the compile error above.

This is described in the Java tutorial here.