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