JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview)

by mfiguiere • 3 years ago

73 65 3 years ago

mfiguiere• 3 years ago

The timeline of its promotion from draft status along with several mentions of JDK 21 in the provided examples make it likely to ship with JDK 21 in September.

kasperni• 3 years ago

As a preview feature

hyperpape2• 3 years ago

The section on how the main method will be resolved is a bit painful. I can’t see a way around it that doesn’t do nasty things for composability and/or backwards compatibility, but it does give me pause. Any situation where you have to ask “which main method in this class will be executed?” is quite bad.

pron7• 3 years ago

Which is why, as part of designing this feature, we ran a corpus search to see what portion of classes with a main method have another main that would be a candidate entry point under this JEP. It was negligible. Additionally, we'll give a linter warning if there's more than one candidate.

pgwhalen3• 3 years ago

As much as it's a crutch in programming language design to say "we don't have to worry too much about the lack of ergonomics in this case, it would be such bad code if this edge case gets run into in the first place," this seems like one of those situations.

Another point: IDEs will be able to tell you which main method will get chosen, which should eliminate at least some uncertainty.

WhereIsTheTruth• 3 years ago

Kotlin and the likes proved them wrong

Glad to see them evolving faster as a result

java-man4• 3 years ago

I feel like this is introducing a change for the sake of change, solving a problem which does not exist. The price of this change is very real: adding complexity and bugs to all the tools, IDEs, code analyzers and the like.

There is negative net benefit to pretty much everyone involved, and for what?

Pet_Ant• 3 years ago

That is literally what is addressed by the first section of the document. Both in "Summary" and in "Goals"

Far from using a separate dialect of Java, students can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow.

I remember when I started with Java 20 years we had a special IDE (BlueJ maybe? DrJava?) that wrapped the main class so that <code>System.out.println("Hello world");</code> was a complete program.

So that is clearly

Do not introduce a separate beginner's dialect of Java.

Perhaps this is in response to Python growing as an initial programming language (IMHO wrongly because types are fundamental to thinking about programming).

They also mention:

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

You can question the merits or trade-offs, but it's very clearly spelled out.

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

java-man4• 3 years ago

Is this really what students struggle with?

I think it is important to be able to determine the root cause of a problem first. Do students find difficult to write "public static void main(String[] args)" or do they find difficulty understanding the concepts of a public method, a static method, a void method? Perhaps then we should focus on teaching these concepts, which are essential to java, first, instead of undermining the core of the language and the platform.

Neither "goals" nor "summary" can explain away why this can solve the problem this JEP purports to solve.

This is my opinion, of course.

ht_th3• 3 years ago

In my experience teaching introductory programming with Java, the problem is very real. For beginning programmers, making sense of the first Java program(s) results too often in misunderstanding of all sorts of concepts.

Of course, you can tell students to ignore most of the code until later in the course when they'll learn all about it, but that doesn't work. They'll make sense of the code within their limited understanding of programming and frames of reference. They'll build local theories of how and why these programming elements, like "static", "class", "main", "String[]" etc. fit together, how they relate to error messages they get when their programs don't compile or don't work.

Then, when they do reach the place in the course when they're to learn all about these concepts, they have to reconcile their own local theories with the material at hand to create a more thorough and evolved understanding of the concept. That's often not an easy process. In many introductory programming courses, there's not much time for reflection. As a result, their evolving understanding is likely closer to their initial understanding instead of the ones we aim at as teachers.

What's not helping here is that as experienced programmers who have developed a deep understanding of these concepts to understand novice's point-of-view and their struggles with the material.

Learning and teaching is hard!

justin_oaks2• 3 years ago

Thanks for explaining the problem. Do you think the proposed changes will help significantly and will be worth the trouble?

smarks• 3 years ago

Thanks for raising this issue. What you describe as "local theories" (I'd say "mental model" but I think we're talking about the same thing) is quite important. We expect beginners to come up with erroneous models as they're exposed to stuff; revising and even discarding such models is intrinsic to learning. One of the benefits of this JEP is to minimize the opportunities for beginners to create erroneous mental models.

slaymaker1907• 3 years ago

I've written a ton of Java and I'd find this handy for datetime stuff. Even though I don't use it for my work anymore, I still pull out Java when I need to answer questions like what day is 90 days from now because java.time.* is very well designed. Instead of just using the shell, this makes things a little nicer with less ceremony if I want to do these date calculations in a local file.

justin_oaks2• 3 years ago

I do wonder how much benefit will be gained from this. Is the main method really causing beginners that many problems?

I'd say beginners are much more likely to trip over other problems with the language like using == with String instances, the differences between primitives and objects (e.g. copy-by-value vs copy-by-reference, no methods on a primitive, etc.), or the unending problems with null.

Of course, those may never be resolved, and so we'll have to change something that doesn't really matter instead.

crummy2• 3 years ago

Not sure if you're being sarcastic but the solution to some of those things is on the horizon (e.g. null awareness). Seems like a lot of work is necessary to get there though.

easton• 3 years ago

Why would this cause extreme problems for Java where it didn’t for C# doing the same thing a few years ago? I’m honestly asking not having done Java in a few years, as I remember they both had this “you gotta put all the code in classes” problem.

kaba06• 3 years ago

It is an ultra minimal change, mostly related to loadclassing, nothing else changes in the language spec.

yarg2• 3 years ago

All I can think coming away from this is:

This still seems pretty useless, It'd be nice if java could allow for static interface methods.

    interface Program {
        static void main(String...args);
    }

And then I digressed - heavily.

There have been several times when I've wanted static methods that apply to the specific class - although many of the situations could be shoehorned into a constructor, it's not the best.

You'd also want something like a 'This' meta-class keyword.

    interface Foo extends Comparable<This> {

        static This(A argA, B argB);

        static This difference(This v0, This v1);

        static int compare(This v0, This v1);

        default int compareTo(This other){
            return compare(v0, v1);
        }

    }

    /*
        I want to return an instance of my class' own type (defined in a subclass an so unknown),
        so I pass every implementation itself as its own generic parameter.
    */

    interface Why<W extends Why<W>> implements Comparable<W>{
        W someManipulation();  
    }

    class Foo implements Why<Foo> {
        @Override
        Foo someManipulation(){
            ....
        }
    }

To be honest, I think I reacted to how robust this does not feel.

It also blurs the line between static and instance syntax/functionality in a way that does not seem useful - and given that this is intended to reduce barriers to entry, is quite probably harmfully confusing.

yarg2• 3 years ago

A better example of what I'm thinking (assuming these interfaces are in java.lang to allow for safe operator overloading):

    interface Summable {
        static This sum(This v0, This v1); 
    }

    interface Subtractable {
        static This difference(This v0, This v1); 
    }

    interface Divisible {
        static This quotient(This v0, This v1); 
    }

    interface Mulitiplicable {
        static This product(This v0, This v1); 
    }

    interface Number extends Summable, Subtractable, Divisible, Multiplicable;

    void <N extends Number> doThings(N v0, N v1){
        N sum = v0 + v1;
    }

evntdrvn• 3 years ago

The .NET team just added static interface members in C# 11, because they themselves had this need in order to create System.Numerics:

https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/tu...

https://learn.microsoft.com/en-us/dotnet/api/system.numerics...

clhodapp• 3 years ago

I'd love to see them follow with full-blown package-level methods and fields at some point (as alluded to in the alternatives) but this seems like a great minimal change to address a real pain point with learning to code in Java.

johnfn• 3 years ago

Pretty nice! Makes me wonder why they didn't take the final step and say that anything not inside `void main()` gets bundled up into an implicit function run first.

djur2• 3 years ago

It's addressed near the end:

Eliminating the main method altogether may seem like the natural next step, but it would work against the goal of gracefully evolving a first Java program to a larger one and would impose some non-obvious restrictions (see below):

The "see below" boils down to there being a number of differences between how class-level and method-level code units (fields vs. variables) work, and blurring the line there isn't worth the minor additional effort of writing a main() method.

hyperpape2• 3 years ago

Question that just now occurs to me: what if you have the follow class and invoke it? (typing without an IDE, forgive any compilation errors). I can imagine answers, but I’m not sure if the JEP explains which one will happen (genuinely unsure, I could’ve easily missed it).

public class Foo {

    int x;

    public Foo(int x) {
        this.x = x;
    }
    
    void main() {
         System.out.println(x);
    }
}

pron7• 3 years ago

The JEP says:

If a launched class has no static main method but has a non-private zero-parameter constructor ... and a non-private instance main method, then construct an instance of the class... [and] invoke the instance main method

Your class doesn't have a zero-parameter constructor nor a suitable static main, so launching it as a program will fail (as it would today).

specialist3• 3 years ago

Love it.

Don't forget to support shebang. So we can finally use Java as a system scripting language.

Maybe something like:

    #!/usr/bin/env java

And maybe also allow specifying the runtime version:

    #!/usr/bin/env java-12.0.*

carimura• 3 years ago

Like this? https://dev.java/learn/single-file-program/

specialist3• 3 years ago

Aha! Exactly like that. Nicely spotted.

oweiler• 3 years ago

JBang can do this: https://www.jbang.dev

specialist3• 3 years ago

Looks amazing. Thanks!

When I write the Getting Started for my (FOSS) library, I'll definitely make a JBang variant. (Gitpod and SDKMAN also look interesting.)

The use of Groovy's @Grab et al is also interesting. I'm eager to see how the dependency, imports, modules, local repo cache story, etc story plays out.

Even after all this time, the Java stack still hasn't found its sweet spot. Though I confess I don't know what that'd look like.

tpoacher3• 3 years ago

My 2¢ is that this will probably do more to confuse than to enlighten students.

Getting your "first" program off the ground quickly is good, but only if it doesn't cripple your understanding of what's going on for months later.

For me the main thing that confuses the crap out of students is how people who introduce java tend to take "shortcuts" and bundle all functionality under the sun into a single class, which then also has a main method at the end. Presumably this is done so that everything is a single file, or can fit in a single presentation slide. But then suddenly your main looks like it's calling its container class to make objects of "itself" that contain new "mains", at which point your student has lost the plot completely.

The simplest thing to keep things clean and self explanatory is to separate everything that isn't "main-related" into its own class (preferably another file if public), and then keep a nice clean public class called "Main" which contains 'only' the main method. Then you get to explain nicely how public classes have their own files, and if you attempt to run this class from the terminal, java will look for the 'main' function, and how this therefore needs to be public, static because you're running it straight from the class, void because you don't depend on it returning a value (which also makes for a nice intermission on how c returns status as an int, but java has a special mechanism instead).

I do agree with the end of the JEP though; if you want to teach simple snippets like System.out.println, jshell is a nice way to do this, if you want to delay talking about classes and their methods.

pron7• 3 years ago

But then suddenly your main looks like it's calling its container class to make objects of "itself" that contain new "mains", at which point your student has lost the plot completely.

Exactly. This is one of the problems this JEP attempts to solve.

separate everything that isn't "main-related" into its own class ... and then keep a nice clean public class called "Main" which contains 'only' the main method. Then you get to explain nicely how public classes have their own files, and if you attempt to run this class from the terminal, java will look for the 'main' function, and how this therefore needs to be public, static because you're running it straight from the class, void because you don't depend on it returning a value

Only then you've taught a number of programming-in-the-large concepts as well as a bunch of Java technicalities -- all designed for the purpose of building large programs in a team -- before teaching what a computer program is.

However, if you use this feature to teach your students and encounter a problem, we would be interested to hear your experience on the amber-dev mailing list.

tpoacher3• 3 years ago

Java has had a nice focus on "decluttering" improvements lately; I think it's a nice focus to have (if done carefully), as 'verbosity' has always been one of the supposed pain points of java. I would welcome this JEP in this light.

I see this as great for developers already familiar with the language in making code more streamlined. But it's along a similar vein to, say, "anonymous classes can be expressed as lambdas which can in turn be expressed as method references". Or, say, the 'var' keyword as a way to automatically infer the variable type and how memory will be allocated for it, on the basis of the applied constructor. In both cases, the last step may be a nice, simple-looking expression, but it hides a lot of underlying complexity and context, which you need to understand properly to use it effectively.

So the part I 'object' to in the wording of the JEP is the educational intent/strategy implied in the summary. For me there is a big difference between something like "introduce complex idea A at a higher level because simpler idea B depends on it", vs "obfuscate the true nature of A to pretend B can be understood in isolation, and deal with the resulting confusion later". Learning works by creating basic blocks of understanding, consolidating them, and then using them to build more complex blocks later on. Relying on a faulty foundation, hoping to come back and re-build it later on is generally not the best educational strategy (in my humble view).

So from an educational point of view, for me this does not make my job simpler. If I wanted my students to build a solid foundation of understanding, I would have to first explain what classes are, what static methods are, how methods can NOT in fact live outside a class in java, and only THEN explain that "to make things less verbose, in this VERY specific case, java allows you some syntactic-sugar to hide some of that complexity under a simpler-looking syntax, that would otherwise look weird in standard java".

But yes, having said all that, this seems like a nice proposal for the language more generally, that could lead to further similar improvements down the line, and I would be in favour of it! Great work!

paulddraper• 3 years ago

Presumably this is done so that everything is a single file

Putting code in a single file is definitely an asset for instruction, whether Java, C, Python, JavaScript, etc.

That said, a Java file can have multiple classes (though just one public class).

https://dev.java/learn/single-file-program/

yyyk2• 3 years ago

That's basically C# top-level programs[0]. IMHO, In C# these are a mixed bag, because once a project becomes more complex a file without a class looks out of place, so it's a feature for beginners/very simple programs. It was controversial enough that VS eventually included an option to create projects without using this...

From the questioning around "needs to import basic utility classes", I'm guessing the feature following this would be something like C# implicit usings?

[0] https://devblogs.microsoft.com/dotnet/c-9-0-on-the-record/#t...

IIRC C# doesn't have the complex main selection as in here because it relies on csproj files.

pjmlp• 3 years ago

Working with both stacks, I really hope Java doesn't start going through the C# trends of fighting Python and JS on lines of code to produce an "Hello World" application.

Next step, language changes for Jakarta EE/Spring/Quarkus/Helidon minimal APIs.

yyyk2• 3 years ago

Well, ASP.NET (Core) was startup was not exactly intuitive. How many people could type it up without a template? Routing was also way more complex than necessary...

kaba06• 3 years ago

If you have an anonymous class, it can’t be referenced from elsewhere (it has no defined class name) so it is strictly only for small projects, which is imo the correct choice.

But it is easy to “name” it when the program have to grow.

bhawks2• 3 years ago

Now students will need to learn the pain of versioning on their first day of class.

Bob: I get this weird error when I run this example from class.

Sally: Works for me! Hey can you try running this?

Bob: oh that works, lots of extra stuff in it. I guess I have to copy all of these things along for an app to work anywhere.

Sally: I guess so - it's weird the simple example works on my laptop and not yours.

Bob: must be a compiler bug, I hear about those alot in the compsci lab.

Personally I think that the compiler should generate a synthetic main entry point when it encounters code that matches the new "launch protocol". It provides a degree of portability and repeatability over relying on the runtime to select the entry point. There are probably downsides here too.

kaba06• 3 years ago

How many classes do you have that have a function named “main”?

bhawks2• 3 years ago

Approximately none. Which is why I would be fine with javac generating a synthetic public static void main(string[] args) that forwards to it when the pattern is encountered.

In this setup the generated classes/jars work fine without extra flags to java and even work on older jvm installations if you pass the right flags to javac at build time. I really struggle to come up with a reason to implement this as a change to java vm over just javac.

kaba06• 3 years ago

I really like this feature as they managed to cut down on verbosity with only a tiny amount of change to the language, the bigger part is done by simply changing the default classloader (it accepting not only public static void main(String… args))

teo_zero2• 3 years ago

C is already much better, but we still have some boilerplate. Currently this is the bare minimum:

  #include <stdio.h>
  int main() {
    printf("Hello world\n");
    return 0;
  }

But I wish we could get rid of that "boilerplate" #include. I think compilers could add it by themselves when needed (many already suggest it to you if you forget it, so they do know when it's the case).

On the other hand I wouldn't get rid of the explicit return from main(), as it has an important pedagogical function.

JohnTordur• 3 years ago

I disagree, #include <stdio.h> implies a system which has a stdout or stdin. That is not necessarily a case for embedded systems, where maybe at most you can blink an LED as a form of user output.

teo_zero2• 3 years ago

I don't disagree, but the compiler could insert it automatically when you need it. In those rare cases where e.g. you want to use a function called printf() that's not the standard printf(), you explicitly opt out of the default via a compiler argument, a #pragma, etc.

sgt• 3 years ago

How about a Main.java file that just contains the body of main() E.g

  println("Hello");

Without even the System.out

Will allows for easy experimentation. Once you need to use methods, put it into a static method and a class.

ajkjk• 3 years ago

This is easily 20 years overdue. It was obviously a major problem in the 2000s. It's not even about pedagogy -- the lack of ceremony for simple calculations is one of the reasons I reach for Python or even Typescript before Java to do one-off experiments, programming puzzles, or anything else.

JEP 445: Flexible Main Methods and Anonymous Main Classes (Preview)

Related Stories