<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <blockquote type="cite" cite="mid:06823323-6214-438A-80A7-184310F01C55@oracle.com">
      <div class="">(1) Instead of having a magic “unnamed” class, which
        has bizarre properties such as not having a constructor (or at
        least not a constructor you can mention in a `new` expression),
        only to then require a second magic rule about what you put in
        the command line “java …”, why not simply use the much more
        obvious rule that if a compilation unit doesn't have a class
        header, then a class header is _supplied_ by the compiler, and
        the name of the class is taken from the filename of the
        compilation unit?</div>
    </blockquote>
    <br>
    The implementation does something like this, which is almost a
    forced move due to the vagaries of the various extralinguistic rules
    like "Foo.class should not contain a class other than Foo" (enforced
    by the class loader.)  So indeed, if Foo.java contains an "unnamed"
    class, Foo.class will contain a class called "Foo".  <br>
    <br>
    The main difference (if there is one) is the meaning of the name Foo
    in the body of the class.  This relates to another "unnamed" JEP in
    flight, which is "unnamed variables", such as:<br>
    <br>
        var _ = mySideEffects();<br>
    <br>
    Here, _ refers to a variable whose name is not entered into the
    symbol table, and is therefore write-once, read-none.  The proposal
    herein for unnamed classes treats the class name the same way. 
    (Full disclosure: since there is a Foo.class with a class called Foo
    in it, it is hard to stop _other_ classes from instantiating it.)<br>
    <br>
    What you are suggesting is to instead take that
    extralinguistically-derived name and make it official.  This reduces
    some of the restrictions (you can have constructors) but seems like
    it creates new ghosts from different machines, since now there is a
    name that has meaning in the language but which didn't come from any
    Java source code.  <br>
    <br>
    <blockquote type="cite" cite="mid:06823323-6214-438A-80A7-184310F01C55@oracle.com">
      <div class="">(2) Instead of complicating the Java launch
        protocol, why not leave it along, and instead use the existing
        mechanism of “in situation X, if the user fails to provide
        method Y, the compiler will provide a definition automatically”?
         Specifically, in a compilation unit named Foo.java for which a
        class header has to be provided automatically, if a method with
        signature “main()” is present but no static method with
        signature “main(String[])” is present, then a static method with
        signature “main(String[])” is automatically provided by the
        compiler.</div>
    </blockquote>
    <br>
    Saying that you can only use these two mechanisms together seems a
    sharp edge that users will get caught on.  The two simplifications
    are orthogonal; there is "instance main" and there is "low ceremony
    classes", but coupling the two in this way means you have to give up
    one if you don't use the other.  <br>
    <br>
    However, your "if you don't provide..." approach is an entirely
    valid way to implement "instance main" -- by injecting additional
    methods into the compiled class rather than modifying the launcher. 
    It would be specified slightly differently (since it is also
    reflectively visible) but that's OK.   <br>
    <br>
    <blockquote type="cite" cite="mid:06823323-6214-438A-80A7-184310F01C55@oracle.com">(3)
      Instead of speaking of automatic imports, speak of the compiler
      automatically providing certain import statements if the
      compilation unit doesn’t have a class header.
    </blockquote>
    <br>
    If we did this, when a class "graduates" from a low-ceremony class
    to a full class, then they'd have to go back and fix up all the
    println calls, and similarly it would put users in a position of
    "you can have ceremony reduction X, but only if you qualify for
    ceremony reduction Y."  It is surely a weaker argument that
    `println` needs to be effectively global, but after having
    programmed without saying "System.out" in front of println for only
    a few weeks, one already feels like going back is a punishment. 
    (Its small, I know, but in some situations you type it a lot.)  We
    have also seen the need for automatic imports elsewhere, such as in
    JEP 430, where a feature of the language carries with it a static
    member (the STR and FMT template processors), and requiring an
    explicit static import seems burdensome.  <br>
    <br>
    Taken together, coupling "instance main" and "auto static imports"
    to "no class header" means that we have created a "beginners
    dialect" which is different, and which has to be unlearned and
    undone as soon as a class graduates.  I would prefer to have these
    be orthogonal features to the extent possible.  <br>
    <br>
    <blockquote type="cite" cite="mid:06823323-6214-438A-80A7-184310F01C55@oracle.com">
      <div class="">That way _everything_ (the name of class when a
        class header is not provided, the behavior when you write
        variously abbreviated definitions of method `main`, and the
        automatic importation of certain libraries) can be explained in
        terms of source-code rewrites that the programmer can do once
        the programmer learns enough about more advanced features.</div>
      <div class=""><br class="">
      </div>
      <div class="">—Guy</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <div class="">
          <div><br class="">
            <blockquote type="cite" class="">
              <div class="">On Sep 28, 2022, at 1:57 PM, Brian Goetz
                <<a href="mailto:brian.goetz@oracle.com" class="moz-txt-link-freetext" moz-do-not-send="true">brian.goetz@oracle.com</a>>
                wrote:</div>
              <br class="Apple-interchange-newline">
              <div class="">
                <div class=""><font class="" size="4"><font class="" face="monospace">At various points, we've explored
                      the question of which program elements are most
                      and least helpful for students first learning
                      Java.  After considering a number of alternatives
                      over the years, I have a simple proposal for
                      smoothing the "on ramp" to Java programming, while
                      not creating new things to unlearn. 
                      <br class="">
                      <br class="">
                      Markdown source is below, HTML will appear soon
                      at: <br class="">
                      <br class="">
                          <a class="moz-txt-link-freetext" href="https://openjdk.org/projects/amber/design-notes/on-ramp" moz-do-not-send="true">
https://openjdk.org/projects/amber/design-notes/on-ramp</a><br class="">
                      <br class="">
                      <br class="">
                      # Paving the on-ramp<br class="">
                      <br class="">
                      Java is one of the most widely taught programming
                      languages in the world.  Tens<br class="">
                      of thousands of educators find that the imperative
                      core of the language combined<br class="">
                      with a straightforward standard library is a
                      foundation that students can<br class="">
                      comfortably learn on.  Choosing Java gives
                      educators many degrees of freedom:<br class="">
                      they can situate students in `jshell` or Notepad
                      or a full-fledged IDE; they can<br class="">
                      teach imperative, object-oriented, functional, or
                      hybrid programming styles; and<br class="">
                      they can easily find libraries to interact with
                      external data and services.  <br class="">
                      <br class="">
                      No language is perfect, and one of the most common
                      complaints about Java is that<br class="">
                      it is "too verbose" or has "too much ceremony." 
                      And unfortunately, Java imposes<br class="">
                      its heaviest ceremony on those first learning the
                      language, who need and<br class="">
                      appreciate it the least.  The declaration of a
                      class and the incantation of<br class="">
                      `public static void main` is pure mystery to a
                      beginning programmer.  While<br class="">
                      these incantations have principled origins and
                      serve a useful organizing purpose<br class="">
                      in larger programs, they have the effect of
                      placing obstacles in the path of<br class="">
                      _becoming_ Java programmers. Educators constantly
                      remind us of the litany of<br class="">
                      complexity that students have to confront on Day 1
                      of class -- when they really<br class="">
                      just want to write their first program.  <br class="">
                      <br class="">
                      As an amusing demonstration of this, in her
                      JavaOne keynote appearance in 2019,<br class="">
                      [Aimee Lucido](<a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=BkPPFiXUwYk" moz-do-not-send="true">https://www.youtube.com/watch?v=BkPPFiXUwYk</a>)
                      talked about when<br class="">
                      she learned to program in Java, and how her
                      teacher performed a rap song<br class="">
                      to help students memorize `"public static void
                      main"`.  Our hats are off to<br class="">
                      creative educators everywhere for this kind of
                      dedication, but teachers<br class="">
                      shouldn't have to do this.<br class="">
                      <br class="">
                      Of course, advanced programmers complain about
                      ceremony too.  We will never be<br class="">
                      able to satisfy programmers' insatiable appetite
                      for typing fewer keystrokes,<br class="">
                      and we shouldn't try, because the goal of
                      programming is to write programs that<br class="">
                      are easy to read and are clearly correct, not
                      programs that were easy to type.<br class="">
                      But we can try to better align the ceremony
                      commensurate with the value it<br class="">
                      brings to a program -- and let simple programs be
                      expressed more simply.  <br class="">
                      <br class="">
                      ## Concept overload<br class="">
                      <br class="">
                      The classic "Hello World" program looks like this
                      in Java:<br class="">
                      <br class="">
                      ```<br class="">
                      public class HelloWorld { <br class="">
                          public static void main(String[] args) { <br class="">
                              System.out.println("Hello World");<br class="">
                          }<br class="">
                      }<br class="">
                      ```<br class="">
                      <br class="">
                      It may only be five lines, but those lines are
                      packed with concepts that are<br class="">
                      challenging to absorb without already having some
                      programming experience and<br class="">
                      familiarity with object orientation. Let's break
                      down the concepts a student<br class="">
                      confronts when writing their first Java program:<br class="">
                      <br class="">
                        - **public** (on the class).  The `public`
                      accessibility level is relevant<br class="">
                          only when there is going to be cross-package
                      access; in a simple "Hello<br class="">
                          World" program, there is only one class, which
                      lives in the unnamed package.<br class="">
                          They haven't even written a one-line program
                      yet; the notion of access<br class="">
                          control -- keeping parts of a program from
                      accessing other parts of it -- is<br class="">
                          still way in their future.<br class="">
                      <br class="">
                        - **class**.  Our student hasn't set out to
                      write a _class_, or model a<br class="">
                          complex system with objects; they want to
                      write a _program_.  In Java, a<br class="">
                          program is just a `main` method in some class,
                      but at this point our student<br class="">
                          still has no idea what a class is or why they
                      want one.<br class="">
                      <br class="">
                        - **Methods**.  Methods are of course a key
                      concept in Java, but the mechanics<br class="">
                          of methods -- parameters, return types, and
                      invocation -- are still<br class="">
                          unfamiliar, and the `main` method is invoked
                      magically from the `java`<br class="">
                          launcher rather than from explicit code.  <br class="">
                      <br class="">
                        - **public** (again).  Like the class, the
                      `main` method has to be public, but<br class="">
                          again this is only relevant when programs are
                      large enough to require<br class="">
                          packages to organize them.  <br class="">
                      <br class="">
                        - **static**.  The `main` method has to be
                      static, and at this point, students<br class="">
                          have no context for understanding what a
                      static method is or why they want<br class="">
                          one.  Worse, the early exposure to `static`
                      methods will turn out to be a<br class="">
                          bad habit that must be later unlearned.  Worse
                      still, the fact that the<br class="">
                          `main` method is `static` creates a seam
                      between `main` and other methods;<br class="">
                          either they must become `static` too, or the
                      `main` method must trampoline<br class="">
                          to some sort of "instance main" (more
                      ceremony!)  And if we get this wrong,<br class="">
                          we get the dreaded and mystifying `"cannot be
                      referenced from a static<br class="">
                          context"` error.<br class="">
                      <br class="">
                        - **main**.  The name `main` has special meaning
                      in a Java program, indicating<br class="">
                          the starting point of a program, but this
                      specialness hides behind being an<br class="">
                          ordinary method name.  This may contribute to
                      the sense of "so many magic<br class="">
                          incantations."<br class="">
                      <br class="">
                        - **String[]**.  The parameter to `main` is an
                      array of strings, which are the<br class="">
                          arguments that the `java` launcher collected
                      from the command line.  But our<br class="">
                          first program -- likely our first dozen --
                      will not use command-line<br class="">
                          parameters. Requiring the `String[]` parameter
                      is, at this point, a mistake<br class="">
                          waiting to happen, and it will be a long time
                      until this parameter makes<br class="">
                          sense.  Worse, educators may be tempted to
                      explain arrays at this point,<br class="">
                          which further increases the
                      time-to-first-program.<br class="">
                      <br class="">
                        - **System.out.println**.  If you look closely
                      at this incantation, each<br class="">
                          element in the chain is a different thing --
                      `System` is a class (what's a<br class="">
                          class again?), `out` is a static field (what's
                      a field?), and `println` is<br class="">
                          an instance method.  The only part the student
                      cares about right now is<br class="">
                          `println`; the rest of it is an incantation
                      that they do not yet understand<br class="">
                          in order to get at the behavior they want.<br class="">
                      <br class="">
                      That's a lot to explain to a student on the first
                      day of class.  There's a good<br class="">
                      chance that by now, class is over and we haven't
                      written any programs yet, or<br class="">
                      the teacher has said "don't worry what this means,
                      you'll understand it later"<br class="">
                      six or eight times.  Not only is this a lot of
                      _syntactic_ things to absorb, but<br class="">
                      each of those things appeals to a different
                      concept (class, method, package,<br class="">
                      return value, parameter, array, static, public,
                      etc) that the student doesn't<br class="">
                      have a framework for understanding yet.  Each of
                      these will have an important<br class="">
                      role to play in larger programs, but so far, they
                      only contribute to "wow,<br class="">
                      programming is complicated."  <br class="">
                      <br class="">
                      It won't be practical (or even desirable) to get
                      _all_ of these concepts out of<br class="">
                      the student's face on day 1, but we can do a lot
                      -- and focus on the ones that<br class="">
                      do the most to help beginners understand how
                      programs are constructed.<br class="">
                      <br class="">
                      ## Goal: a smooth on-ramp<br class="">
                      <br class="">
                      As much as programmers like to rant about
                      ceremony, the real goal here is not<br class="">
                      mere ceremony reduction, but providing a graceful
                      _on ramp_ to Java programming.<br class="">
                      This on-ramp should be helpful to beginning
                      programmers by requiring only those<br class="">
                      concepts that a simple program needs.  <br class="">
                      <br class="">
                      Not only should an on-ramp have a gradual slope
                      and offer enough acceleration<br class="">
                      distance to get onto the highway at the right
                      speed, but its direction must<br class="">
                      align with that of the highway.  When a programmer
                      is ready to learn about more<br class="">
                      advanced concepts, they should not have to discard
                      what they've already learned,<br class="">
                      but instead easily see how the simple programs
                      they've already written<br class="">
                      generalize to more complicated ones, and both the
                      syntatic and conceptual<br class="">
                      transformation from "simple" to "full blown"
                      program should be straightforward<br class="">
                      and unintrusive.  It is a definite non-goal to
                      create a "simplified dialect of<br class="">
                      Java for students".<br class="">
                      <br class="">
                      We identify three simplifications that should aid
                      both educators and students in<br class="">
                      navigating the on-ramp to Java, as well as being
                      generally useful to simple<br class="">
                      programs beyond the classroom as well:<br class="">
                      <br class="">
                       - A more tolerant launch protocol<br class="">
                       - Unnamed classes<br class="">
                       - Predefined static imports for the most critical
                      methods and fields<br class="">
                      <br class="">
                      ## A more tolerant launch protocol<br class="">
                      <br class="">
                      The Java Language Specification has relatively
                      little to say about how Java<br class="">
                      "programs" get launched, other than saying that
                      there is some way to indicate<br class="">
                      which class is the initial class of a program (JLS
                      12.1.1) and that a public<br class="">
                      static method called `main` whose sole argument is
                      of type `String[]` and whose<br class="">
                      return is `void` constitutes the entry point of
                      the indicated class.  <br class="">
                      <br class="">
                      We can eliminate much of the concept overload
                      simply by relaxing the<br class="">
                      interactions between a Java program and the `java`
                      launcher:<br class="">
                      <br 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="">
                      <br 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="">
                      <br 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="">
                      <br class="">
                      This small set of changes to the launch protocol
                      strikes out five of the bullet<br class="">
                      points in the above list of concepts: public
                      (twice), static, method parameters,<br class="">
                      and `String[]`.  <br class="">
                      <br class="">
                      At this point, our Hello World program is now:<br class="">
                      <br class="">
                      ```<br class="">
                      class HelloWorld { <br class="">
                          void main() { <br class="">
                              System.out.println("Hello World");<br class="">
                          }<br class="">
                      }<br class="">
                      ```<br class="">
                      <br class="">
                      It's not any shorter by line count, but we've
                      removed a lot of "horizontal<br class="">
                      noise" along with a number of concepts.  Students
                      and educators will appreciate<br class="">
                      it, but advanced programmers are unlikely to be in
                      any hurry to make these<br class="">
                      implicit elements explicit either.  <br class="">
                      <br class="">
                      Additionally, the notion of an "instance main" has
                      value well beyond the first<br class="">
                      day.  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.  Formalizing<br class="">
                      the "instance main" protocol reduces a layer of
                      boilerplate in these cases, and<br class="">
                      defers the point at which we have to explain what
                      instance creation is -- and<br class="">
                      what `static` is.  (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="">
                      <br class="">
                      ## Unnamed classes<br class="">
                      <br class="">
                      In a simple program, the `class` declaration often
                      doesn't help either, because<br class="">
                      other classes (if there are any) are not going to
                      reference it by name, and we<br class="">
                      don't extend a superclass or implement any
                      interfaces.  If we say an "unnamed<br class="">
                      class" consists of member declarations without a
                      class header, then our Hello<br class="">
                      World program becomes:<br class="">
                      <br class="">
                      ```<br class="">
                      void main() { <br class="">
                          System.out.println("Hello World");<br class="">
                      }<br class="">
                      ```<br class="">
                      <br class="">
                      Such source files can still have fields, methods,
                      and even nested classes, so<br class="">
                      that as a program evolves from a few statements to
                      needing some ancillary state<br class="">
                      or helper methods, these can be factored out of
                      the `main` method while still<br class="">
                      not yet requiring a full class declaration:<br class="">
                      <br class="">
                      ```<br class="">
                      String greeting() { return "Hello World"; }<br class="">
                      <br class="">
                      void main() {<br class="">
                          System.out.println(greeting());<br class="">
                      }<br class="">
                      ```<br class="">
                      <br class="">
                      This is where treating `main` as an instance
                      method really shines; the user has<br class="">
                      just declared two methods, and they can freely
                      call each other.  Students need<br class="">
                      not confront the confusing distinction between
                      instance and static methods yet;<br class="">
                      indeed, if not forced to confront static members
                      on day 1, it might be a while<br class="">
                      before they do have to learn this distinction. 
                      The fact that there is a<br class="">
                      receiver lurking in the background will come in
                      handy later, but right now is<br class="">
                      not bothering anybody.<br class="">
                      <br class="">
                      [JEP 330](<a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/330" moz-do-not-send="true">https://openjdk.org/jeps/330</a>)
                      allows single-file programs to be<br class="">
                      launched directly without compilation; this
                      streamlined launcher pairs well with<br class="">
                      unnamed classes. <br class="">
                      <br class="">
                      ## Predefined static imports<br class="">
                      <br class="">
                      The most important classes, such as `String` and
                      `Integer`, live in the<br class="">
                      `java.lang` package, which is automatically
                      on-demand imported into all<br class="">
                      compilation units; this is why we do not have to
                      `import java.lang.String` in<br class="">
                      every class.  Static imports were not added until
                      Java 5, but no corresponding<br class="">
                      facility for automatic on-demand import of common
                      behavior was added at that<br class="">
                      time.  Most programs, however, will want to do
                      console IO, and Java forces us to<br class="">
                      do this in a roundabout way -- through the static
                      `System.out` and `System.in`<br class="">
                      fields.  Basic console input and output is a
                      reasonable candidate for<br class="">
                      auto-static import, as one or both are needed by
                      most simple programs.  While<br class="">
                      these are currently instance methods accessed
                      through static fields, we can<br class="">
                      easily create static methods for `println` and
                      `readln` which are suitable for<br class="">
                      static import, and automatically import them.  At
                      which point our first program<br class="">
                      is now down to:<br class="">
                      <br class="">
                      ```<br class="">
                      void main() {<br class="">
                          println("Hello World");<br class="">
                      }<br class="">
                      ```<br class="">
                      <br class="">
                      ## Putting this all together<br class="">
                      <br class="">
                      We've discussed several simplifications:<br class="">
                      <br class="">
                       - Update the launcher protocol to make public,
                      static, and arguments optional<br class="">
                         for main methods, and for main methods to be
                      instance methods (when a<br class="">
                         no-argument constructor is available); <br class="">
                       - Make the class wrapper for "main classes"
                      optional (unnamed classes);<br class="">
                       - Automatically static import methods like
                      `println`<br class="">
                      <br class="">
                      which together whittle our long list of day-1
                      concepts down considerably.  While<br class="">
                      this is still not as minimal as the minimal Python
                      or Ruby program -- statements<br class="">
                      must still live in a method -- the goal here is
                      not to win at "code golf".  The<br class="">
                      goal is to ensure that concepts not needed by
                      simple programs need not appear in<br class="">
                      those programs, while at the same time not
                      encouraging habits that have to be<br class="">
                      unlearned as programs scale up. <br class="">
                      <br class="">
                      Each of these simplifications is individually
                      small and unintrusive, and each is<br class="">
                      independent of the others.  And each embodies a
                      simple transformation that the<br class="">
                      author can easily manually reverse when it makes
                      sense to do so: elided<br class="">
                      modifiers and `main` arguments can be added back,
                      the class wrapper can be added<br class="">
                      back when the affordances of classes are needed
                      (supertypes, constructors), and<br class="">
                      the full qualifier of static-import can be added
                      back.  And these reversals are<br class="">
                      independent of one another; they can done in any
                      combination or any order.<br class="">
                      <br class="">
                      This seems to meet the requirements of our
                      on-ramp; we've eliminated most of the<br class="">
                      day-1 ceremony elements without introducing new
                      concepts that need to be<br class="">
                      unlearned. The remaining concepts -- a method is a
                      container for statements, and<br class="">
                      a program is a Java source file with a `main`
                      method -- are easily understood in<br class="">
                      relation to their fully specified counterparts.  <br class="">
                      <br class="">
                      ## Alternatives<br class="">
                      <br class="">
                      Obviously, we've lived with the status quo for 25+
                      years, so we could continue<br class="">
                      to do so.  There were other alternatives explored
                      as well; ultimately, each of<br class="">
                      these fell afoul of one of our goals.<br class="">
                      <br class="">
                      ### Can't we go further?<br class="">
                      <br class="">
                      Fans of "code golf" -- of which there are many --
                      are surely right now trying to<br class="">
                      figure out how to eliminate the last little bit,
                      the `main` method, and allow<br class="">
                      statements to exist at the top-level of a
                      program.  We deliberately stopped<br class="">
                      short of this because it offers little value
                      beyond the first few minutes, and<br class="">
                      even that small value quickly becomes something
                      that needs to be unlearned.  <br class="">
                      <br class="">
                      The fundamental problem behind allowing such
                      "loose" statements is that<br class="">
                      variables can be declared inside both classes
                      (fields) and methods (local<br class="">
                      variables), and they share the same syntactic
                      production but not the same<br class="">
                      semantics.  So it is unclear (to both compilers
                      and humans) whether a "loose"<br class="">
                      variable would be a local or a field.  If we tried
                      to adopt some sort of simple<br class="">
                      heuristic to collapse this ambiguity (e.g.,
                      whether it precedes or follows the<br class="">
                      first statement), that may satisfy the compiler,
                      but now simple refactorings<br class="">
                      might subtly change the meaning of the program,
                      and we'd be replacing the<br class="">
                      explicit syntactic overhead of `void main()` with
                      an invisible "line" in the<br class="">
                      program that subtly affects semantics, and a new
                      subtle rule about the meaning<br class="">
                      of variable declarations that applies only to
                      unnamed classes.  This doesn't<br class="">
                      help students, nor is this particularly helpful
                      for all but the most trivial<br class="">
                      programs.  It quickly becomes a crutch to be
                      discarded and unlearned, which<br class="">
                      falls afoul of our "on ramp" goals.  Of all the
                      concepts on our list, "methods"<br class="">
                      and "a program is specified by a main method" seem
                      the ones that are most worth<br class="">
                      asking students to learn early.<br class="">
                      <br class="">
                      ### Why not "just" use `jshell`?  <br class="">
                      <br class="">
                      While JShell is a great interactive tool, leaning
                      too heavily on it as an onramp<br class="">
                      would fall afoul of our goals.  A JShell session
                      is not a program, but a<br class="">
                      sequence of code snippets.  When we type
                      declarations into `jshell`, they are<br class="">
                      viewed as implicitly static members of some
                      unspecified class, with<br class="">
                      accessibility is ignored completely, and
                      statements execute in a context where<br class="">
                      all previous declarations are in scope.  This is
                      convenient for experimentation<br class="">
                      -- the primary goal of `jshell` -- but not such a
                      great mental model for<br class="">
                      learning to write Java programs.  Transforming a
                      batch of working declarations<br class="">
                      in `jshell` to a real Java program would not be
                      sufficiently simple or<br class="">
                      unintrusive, and would lead to a non-idiomatic
                      style of code, because the<br class="">
                      straightforward translation would have us
                      redeclaring each method, class, and<br class="">
                      variable declaration as `static`.  Further, this
                      is probably not the direction<br class="">
                      we want to go when we scale up from a handful of
                      statements and declarations to<br class="">
                      a simple class -- we probably want to start using
                      classes as classes, not just<br class="">
                      as containers for static members. JShell is a
                      great tool for exploration and<br class="">
                      debugging, and we expect many educators will
                      continue to incorporate it into<br class="">
                      their curriculum, but is not the on-ramp
                      programming model we are looking for.  <br class="">
                      <br class="">
                      ### What about "always local"?<br class="">
                      <br class="">
                      One of the main tensions that `main` introduces is
                      that most class members are<br class="">
                      not `static`, but the `main` method is -- and that
                      forces programmers to<br class="">
                      confront the seam between static and non-static
                      members.  JShell answers this<br class="">
                      with "make everything static". <br class="">
                      <br class="">
                      Another approach would be to "make everything
                      local" -- treat a simple program<br class="">
                      as being the "unwrapped" body of an implicit main
                      method.  We already allow<br class="">
                      variables and classes to be declared local to a
                      method.  We could add local<br class="">
                      methods (a useful feature in its own right) and
                      relax some of the asymmetries<br class="">
                      around nesting (again, an attractive cleanup), and
                      then treat a mix of<br class="">
                      declarations and statements without a class
                      wrapper as the body of an invisible<br class="">
                      `main` method. This seems an attractive model as
                      well -- at first.<br class="">
                      <br class="">
                      While the syntactic overhead of converting back to
                      full-blown classes -- wrap<br class="">
                      the whole thing in a `main` method and a `class`
                      declaration -- is far less<br class="">
                      intrusive than the transformation inherent in
                      `jshell`, this is still not an<br class="">
                      ideal on-ramp.  Local variables interact with
                      local classes (and methods, when<br class="">
                      we have them) in a very different way than
                      instance fields do with instance<br class="">
                      methods and inner classes: their scopes are
                      different (no forward references),<br class="">
                      their initialization rules are different, and
                      captured local variables must be<br class="">
                      effectively final.  This is a subtly different
                      programming model that would then<br class="">
                      have to be unlearned when scaling up to full
                      classes. Further, the result of<br class="">
                      this wrapping -- where everything is local to the
                      main method -- is also not<br class="">
                      "idiomatic Java".  So while local methods may be
                      an attractive feature, they are<br class="">
                      similarly not the on-ramp we are looking for.<br class="">
                      <br class="">
                      <br class="">
                    </font></font></div>
              </div>
            </blockquote>
          </div>
          <br class="">
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>