Paving the on-ramp

[Kevin Bourrillion]

On Wed, Sep 28, 2022 at 1:10 PM Brian Goetz <brian.goetz at oracle.com> wrote:

>  - Relax the requirement that the class, and `main` method, be public.
>> Public
>>    accessibility is only relevant when access crosses packages; simple
>> programs
>>    live in the unnamed package, so cannot be accessed from any other
>> package
>>    anyway.  For a program whose main class is in the unnamed package, we
>> can
>>    drop the requirement that the class or its `main` method be public,
>>    effectively treating the `java` launcher as if it too resided in the
>> unnamed
>>    package.
>>
>
> 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.
>
> I think we're saying the same thing; main need not be public.
>


You seemed quite clearly to be offering that for classes in the default
package only.

 - Make the "args" parameter to `main` optional, by allowing the `java`
>> launcher to
>>    first look for a main method with the traditional `main(String[])`
>>    signature, and then (if not found) for a main method with no arguments.
>>
>
> 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?
>
> 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.
>


Oh, yeah, I have a habit of saying "error" when I am always always
perfectly satisfied with a warning. Of course, the warning goes just on the
method that isn't gonna get called, and the user should be advised to
rename it.

 - Make the `static` modifier on `main` optional, by allowing the `java`
>> launcher to
>>    invoke an instance `main` method (of either signature) by
>> instantiating an
>>    instance using an accessible no-arg constructor and then invoking the
>> `main`
>>    method on it.
>>
>
> 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?
>
>
Sorry, just a quick self-reply of clarification: when I said "main IS
static", that was taking Java's model that everything belongs to a class as
*given*. It's not commentary against "main is really a free function".


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.
>


I see that that is "a way" to do a thing. But in my view, implementation
inheritance has messed up every job we've ever given it. :-) It will at the
*least* take me some time and reflection to convince myself that
"inheritable main" isn't horrifying.

Most of the specific counter-arguments I laid out to the non-static main
have dropped out of the thread without acknowledgement, so I'm a little
concerned they'll be forgotten in the discussion.

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20220928/50baa44d/attachment.htm>