<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">Moving to accepting `void
main()` means that we could use an `Application` interface to
require a `void main()`. In fact, your Application could work
like this:<br>
<br>
abstract class Application { <br>
private String[] args;<br>
<br>
final void main(String[] args) { <br>
this.args = args;<br>
}<br>
<br>
protected int argCount() { return args.length; }<br>
protected Object arg(int i) { return args[i]; }<br>
<br>
abstract void main();<br>
}<br>
<br>
So I think you could characterize this as "not closing the
door." <br>
<br>
</font></font><br>
<div class="moz-cite-prefix">On 5/10/2023 4:35 PM, Reinier
Zwitserloot wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAK6PxWN02G8j0sRH2vo98jJ8s1v5mva6QHj38Xz7PBkRSXg9vw@mail.gmail.com">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On 10 May 2023 at 22:06:35,
Brian Goetz <<a href="mailto:brian.goetz@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">brian.goetz@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite"> What you (and others who play this card) don't
realize is: you are actually arguing for "Let's cancel this
project right now, because what we can reasonably deliver is
not good enough." </blockquote>
</div>
<br>
<div dir="ltr"><font style="font-size:13px" face="monospace">I was
more shooting for a compromise; check if the steps proposed in
JEP445 don’t close doors that we might want to leave open.
Rereading my earlier post, I can see how they can be
misconstrued as a hasty grasp for the emergency break on
JEP445.</font></div>
<div dir="ltr"><font style="font-size:13px" face="monospace"><br>
</font></div>
<div dir="ltr"><font style="font-size:13px" face="monospace">For
example, that issue with main not needing to be public bothers
me a little bit - changing the rules in some future java
version that a source file containing an unnamed class will
now be considered as:</font></div>
<div dir="ltr"><font style="font-size:13px" face="monospace"><br>
</font></div>
<div dir="ltr"><font style="font-size:13px" face="monospace">class
$Unnamed extends Application {}</font></div>
<div dir="ltr"><font style="font-size:13px" face="monospace"><br>
</font></div>
<div dir="ltr"><font style="font-size:13px" face="monospace"><br>
</font></div>
<div dir="ltr"><font face="menlo, monospace">may not be all that
backwards breaking. Yes, this unnamed class would now extend
something else, but other than getClass() you can’t access
this class (as it is unnamed), so does it matter that it
extends Application instead of Object? Also, of course, this
now adds a bunch of methods to the namespace that weren’t
there before and which could possibly clash with methods
written in code prior to such an update. But, that’s an issue
most library updates have to grapple with - there is clearly
room to decide that the value of such a feature is sufficient
to cover the cost of introducing such a backwards break.
However, if the main methods in these unnamed classes don’t
have to be <code style="border:1px solid
rgb(206,206,206);background-color:rgb(244,244,244);padding:0px
2px;border-radius:2px">public</code> right now because
JEP445 says they don’t have to be, and <i>solely in light of
that</i>, some potential
future JEP445-part2-unnamed-boogaloo gets stuck because it’s
just too much voodoo magic to decree by JEP that in an unnamed
class, <code style="border:1px solid
rgb(206,206,206);background-color:rgb(244,244,244);padding:0px
2px;border-radius:2px">main()</code> doesn’t actually have
to be declared <code style="border:1px solid
rgb(206,206,206);background-color:rgb(244,244,244);padding:0px
2px;border-radius:2px">public</code> <span style="font-size:13px">(also taking into consideration how
silently upgrading a method’s access level is a bit scary
from a security perspective!) - then perhaps that is the one
thing JEP445 should get rid of. The compiler is free to call
out: Hey, this <i>has</i> to be public - an error message
crafted for this specific situation. Just to leave the door
open to a future update that really does try to redesign the
launch procedure.</span></font></div>
<div dir="ltr"><font style="font-size:13px" face="monospace"><br>
</font></div>
<div dir="ltr"><font style="font-size:13px" face="monospace"><br>
</font></div>
<div dir="ltr"><font style="font-size:13px" face="monospace">Other
than that one point I think a JEP445-part-2 is at least still
a plausible future place java can go, without having to tie
ourselves into knots.</font></div>
<div dir="ltr"><font style="font-size:13px" face="monospace"><br>
</font></div>
<div dir="ltr"><font face="monospace">And, sure, yes, at least
create awareness of what perfection would look like. I’m glad
to hear this was all considered before and rejected - that
relieves some worries (Team OpenJDK has some experience with
this job, but, from personal experience, it can be quite
difficult to walk a mile in the shoes of a java newbie when
you have decades of experience, or even simply keep an open
mind and question things you’ve gotten used to).</font></div>
<div dir="ltr"><br>
</div>
<blockquote style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex" class="gmail_quote" type="cite">
<div dir="ltr"><span style="font-family:monospace;font-size:large">But when you
frame the argument as "if you don't do</span><span style="font-family:monospace;font-size:large"> </span><span style="font-family:monospace;font-size:large">more, you have
failed" (that's what "doesn't accomplish what it</span><span style="font-family:monospace;font-size:large"> </span><span style="font-family:monospace;font-size:large">should"
means), you are arguing "let's cancel the project.</span><font size="4" face="monospace">”</font></div>
</blockquote>
<div><br>
</div>
<font face="menlo, monospace">I did say: Does not <i>fully</i> accomplish
what it should. I would consider some of JEP445’s goals as
failed if <code style="border:1px solid
rgb(206,206,206);background-color:rgb(244,244,244);padding:0px
2px;border-radius:2px">System.out</code>, misuse of <code style="border:1px solid
rgb(206,206,206);background-color:rgb(244,244,244);padding:0px
2px;border-radius:2px">Scanner</code> , and the structural
typed nature of <code style="border:1px solid
rgb(206,206,206);background-color:rgb(244,244,244);padding:0px
2px;border-radius:2px">main()</code> aren’t addressed. Some
would be met. I don’t think it’s worthwhile for me attempt to
judge if the goals that remain are valuable enough to continue
the work on JEP445: That’s the job of the various decision
makers and core contributors to the OpenJDK project, my opinion
on ‘worth’ doesn’t factor into such a decision much I would
imagine.</font>
<div><br>
<div>
<div class="gmail_signature" data-smartmail="gmail_signature"> --Reinier
Zwitserloot<br>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>