<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Another safer approach we are playing with is to synthesize a public static void main method in an unnamed class when missing. The contents of that method would then invoke the user's main.
<div class=""><br class="">
</div>
<div class="">Cheers,</div>
<div class=""><br class="">
</div>
<div class="">— Jim</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Sep 28, 2022, at 4:49 PM, Kevin Bourrillion <<a href="mailto:kevinb@google.com" class="">kevinb@google.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">Virtuous.</div>
<div class=""><br class="">
</div>
<div class="">The quips about horses having fled the barn are coming, but whether they did is irrelevant; let's just make Java better now.</div>
<div class=""><br class="">
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 28, 2022 at 10:57 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank" class="">brian.goetz@oracle.com</a>> wrote:<br class="">
</div>
<div dir="ltr" class="gmail_attr"><br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><font size="4" class=""><font face="monospace" class="">## Concept overload<br class="">
</font></font></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I like that the focus is not just on boilerplate but on the offense of forcing learners to encounter concepts they *will* need to care about but don't yet.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><font size="4" class=""><font face="monospace" class=""> - Relax the requirement that the class, and `main` method, be public. Public<br class="">
accessibility is only relevant when access crosses packages; simple programs<br class="">
live in the unnamed package, so cannot be accessed from any other package<br class="">
anyway. For a program whose main class is in the unnamed package, we can<br class="">
drop the requirement that the class or its `main` method be public,<br class="">
effectively treating the `java` launcher as if it too resided in the unnamed<br class="">
package.<br class="">
</font></font></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Alternative: drop the requirement altogether. Most main methods have no desire to make themselves publicly callable as `TheClass.main(args)`, but today they are forced to expose that API anyway. I feel like it would still be conceptually clean to
say that `public` is really about whether other *code* can access it, not whether a VM can get to it at all.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><font size="4" class=""><font face="monospace" class=""> - Make the "args" parameter to `main` optional, by allowing the `java` launcher to<br class="">
first look for a main method with the traditional `main(String[])`<br class="">
signature, and then (if not found) for a main method with no arguments.<br class="">
</font></font></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">This seems to leave users vulnerable to some surprises, where the code they think is being called isn't. Why not make it a compile-time error to provide both forms?</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><font size="4" class=""><font face="monospace" class=""> - Make the `static` modifier on `main` optional, by allowing the `java` launcher to<br class="">
invoke an instance `main` method (of either signature) by instantiating an<br class="">
instance using an accessible no-arg constructor and then invoking the `main`<br class="">
method on it.<br class="">
</font></font></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I'll give the problems I see with this, without a judgement on what should be done.</div>
<div class=""><br class="">
</div>
<div class="">What's the whole idea of main? Well, it's the entry point into the program. But now it's <i class="">not</i> really the entry point; finding the entry point is more subtle. (Okay, I concede that static initializers are run first either way; that
undercuts *some* of the strength of my argument here.)</div>
<div class=""><br class="">
</div>
<div class="">Even if this is okay when I'm writing my own new program, understanding it as I go, then suppose someone else reads my program. That person has the burden of remembering to check whether `main` is static or not, and remembering that some constructor
code is happening first if it's not. Classes that have both main and a constructor will be a mixture of some that call them in one order and some in the other. That's just, like, messy.</div>
<div class=""><br class="">
</div>
<div class="">And is it even clear, then, why the VM shouldn't be passing `args` to the <i class="">constructor</i>, only hoarding it until calling `main`?<br class="">
</div>
<div class="">
<div class=""><br class="">
</div>
</div>
<div class="">On a deep conceptual level... I'd insist that main() *is static*. It is *the* single entry point into the program; what could be more static than that? But thinking about our learner, who wrote some `main`s before learning about static. The instant
they learn `static` is a keyword a method can have, they'll "know" one thing about it already: this is going to be something new that's *not* true of main(). But then they hear an explanation that fits `main` perfectly?</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><font size="4" class=""><font face="monospace" class="">Because excessive use of `static` is considered a code smell, many<br class="">
educators encourage the pattern of "all the static `main` method does is<br class="">
instantiate an instance and call an instance `main` method" anyway.</font></font></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Heavy groan. In my opinion, some ideas are too misguided to take seriously.</div>
<div class=""><br class="">
</div>
<div class="">The value in that practice is if instance `main` accepts parameters like `PrintStream` and `Console`, and static main passes in `System.out` and `System.console()`. That makes all your actual program logic unit-testable. Great! This actually strikes
directly at the heart of what the entire problem with `static` is! But this isn't the case you're addressing.</div>
<div class=""><br class="">
</div>
<div class="">Static methods are not a code smell! Static methods that ought to be overrideable by one of their argument types (Collections.sort()), sure. Static mutable state is a code smell, definitely -- but a method that touches that state is equally problematic
whether it itself is static or not. There are some code smells around `static`, but `static` itself is fresh and flowery.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=""><font size="4" class=""><font face="monospace" class="">(Further, allowing the `main` method to be an instance method<br class="">
means that it could be inherited from a superclass, which is useful for simple<br class="">
frameworks such as test runners or service frameworks.)<br class="">
</font></font></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">This does not give me a happy feeling. Going into it is a deep discussion though.</div>
<div class=""><br class="">
</div>
<div class="">Rest of the response coming soon, I hope.</div>
</div>
<div class=""><br class="">
</div>
<div class="">Just to mention one additional idea. We could permit `main` to optionally return `int`, becoming the default exit status if `exit` is never called. Seems elegant for the rare cases where you care about exit status, but (a) would this feature get
in the way in *any* sense for the vast majority of cases that don't care, or (b) are the cases that care just way too rare for us to worry about?</div>
<div class="">
<div class=""><br class="">
</div>
</div>
<div class="">I'm not sure about (a). But (b) kinda seems like a yes.</div>
<div class=""><br class="">
</div>
-- <br class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="">
<div dir="ltr" class="">
<div class="">
<div dir="ltr" class="">
<div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif" class="">
<span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px" class="">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px" class=""> Java
Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px" class=""> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px" class=""> <a href="mailto:kevinb@google.com" target="_blank" class="">kevinb@google.com</a></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</body>
</html>