<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:CAGKkBkvNzrfBKiYpr+eGT2ruTb0c6=C7LX1jbQtWmWsanWFwPw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div><font size="4"><font face="monospace"> - Relax the
requirement that the class, and `main` method, be
public. Public<br>
accessibility is only relevant when access crosses
packages; simple programs<br>
live in the unnamed package, so cannot be accessed
from any other package<br>
anyway. For a program whose main class is in the
unnamed package, we can<br>
drop the requirement that the class or its `main`
method be public,<br>
effectively treating the `java` launcher as if it
too resided in the unnamed<br>
package.<br>
</font></font></div>
</blockquote>
<div><br>
</div>
<div>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>
</div>
</blockquote>
<br>
I think we're saying the same thing; main need not be public. <br>
<br>
<blockquote type="cite" cite="mid:CAGKkBkvNzrfBKiYpr+eGT2ruTb0c6=C7LX1jbQtWmWsanWFwPw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div><font size="4"><font face="monospace"> - Make the
"args" parameter to `main` optional, by allowing the
`java` launcher to<br>
first look for a main method with the traditional
`main(String[])`<br>
signature, and then (if not found) for a main
method with no arguments.<br>
</font></font></div>
</blockquote>
<div><br>
</div>
<div>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>
</div>
</blockquote>
<br>
Currently, the treatment of methods called "main" is "and also"; it
is a valid method, *and also* (if it has the right shape) can be
used as a main entry point. Making this an error would take some
valid programs and make them invalid, which seems a shift in the
interpretation of the magic name "main". A warning is probably
reasonable though.<br>
<br>
<blockquote type="cite" cite="mid:CAGKkBkvNzrfBKiYpr+eGT2ruTb0c6=C7LX1jbQtWmWsanWFwPw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div><font size="4"><font face="monospace"> - Make the
`static` modifier on `main` optional, by allowing the
`java` launcher to<br>
invoke an instance `main` method (of either
signature) by instantiating an<br>
instance using an accessible no-arg constructor and
then invoking the `main`<br>
method on it.<br>
</font></font></div>
</blockquote>
<div><br>
</div>
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>
</blockquote>
<br>
John likes to say "static has messed up every job we've ever given
it", and while that seems an exaggeration at first, often turns out
to be surprisingly accurate. One subtle thing it messes up here is
that one cannot effectively inherit a main() method. But inheriting
main() is super useful! Consider a TestCase class in a test
framework, or an AbstractService class in a services framework. If
the abstract class can provide the main() method, then every test
case or service _is also a program_, one which runs that test case
or service. <br>
<br>
But, there is cheese-moving here. In the old model, "main" is just
a disembodied method, which only accidentally lives in a class, and
drags the class along for the ride. In this model, main-ness moves
up the stack, becoming a property of a class, not just something a
class has. <br>
<br>
This tension is evident in JLS 12, which defines the interaction
with main. It is full of wiggle words, because it is trying to
pretend that Java has no concept of "program", just classes, but at
the same time, there has to be a way to get the computation
started. The JLS tries to pretend that "program" is defined almost
extralinguistically (by appeal to an unspcified launcher program
that exists outside of the language), but nearly trips over its own
feet trying to have it both ways. <br>
<br>
The debate among educators about whether main should be allowed to
do anything it wants, or should only instantiate an object and call
a single method, illustrates this tension. So what is really going
on here is bringing the notion of "program" to classes in a less
nailed-on-the-side way. <br>
<br>
<blockquote type="cite" cite="mid:CAGKkBkvNzrfBKiYpr+eGT2ruTb0c6=C7LX1jbQtWmWsanWFwPw@mail.gmail.com">
<div dir="ltr">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><br>
</div>
</div>
<div>I'm not sure about (a). But (b) kinda seems like a yes.</div>
<br>
</div>
</blockquote>
<br>
Considered this (since C lets you do this.) Since Java doesn't let
you overload on return types, we have the option to do this later
without making the search order any more complicated, so I left it
out. <br>
<br>
</body>
</html>