JDK-8319252 : CSR JEP 463: JLS Changes for Implicitly Declared Classes and Instance Main Methods (Second Preview)
  • Type: CSR
  • Component: specification
  • Sub-Component: language
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 22
  • Submitted: 2023-11-01
  • Updated: 2023-11-23
  • Resolved: 2023-11-17
Related Reports
CSR :  
JDK-8318294 - Implement JEP 463: JLS Changes for Implicitly Declared Classes and Instance Main Methods (Second Preview)
Relates :  
JDK-8306113 - Implementation for JEP 445: Unnamed Classes and Instance Main Methods (Preview)
Relates :  
JDK-8308111 - JLS changes for Unnamed Classes and Instance main Methods (Preview)
Description
This is the CSR for the Java Language Specification changes of 
[JEP 463 Implicitly Declared Classes and instance `main` methods (Second Preview)](https://bugs.openjdk.org/browse/JDK-8315398)

Summary
-------
Add flexible `main` methods and implicitly declared main classes to the Java
language. This is a
[preview language feature and API](http://openjdk.java.net/jeps/12).

Problem
-------

The Java language necessitates the explicit use of some programming-in-the-large
constructs such as classes and access control even for the simplest of programs.
This makes the language unnecessarily difficult to learn for programming
beginners, and adds too much noise to small programs.


Solution
--------

This change adds two features: 

1.  flexible `main` methods allow the main entry point to a program to allow
    different signatures. In particular, they allow a `main` method to have no
    parameters, they allow a `main` method to have any non-private access, and
    they allow it to be an instance method. An instance `main` method can be
    invoked by the launcher if the launched class has a non-private no-args
    constructor.

2.  A Java file that declares one or more methods outside a class declaration is
    defined to implicitly declare a top-level class. The name of this class is
    not specified, but in simple implementations of the Java SE Platform, where
    compilation units are stored in files, the name of this implicitly declared
    class would typically be the name of the file containing the simple
    compilation unit minus any extension (such as .java or .jav). 


Specification
-------------

Details of the changes to the Java Language Specification & Java Virtual Machine
Specification are attached and are also available at
[https://cr.openjdk.org/~gbierman/jep463/latest/](https://cr.openjdk.org/~gbierman/jep463/latest/). 

Changes described above are only available with `--enable-preview`. No class
file changes are required.
Comments
Thanks [~prappo]!
23-11-2023
Maybe that's not the right place, but let me report a few trivial typos in the attached most recent specification: ``` An simple compilation unit consists of ^ zero or more import declarations that allow classes and interface from other packages ^ ```
23-11-2023
In discussion with [~mcimadamore] we came to the conclusion that there should be no error in this case since there is no conflict with any symbol. If did provide an error then the spec would have to add a convoluted explanation of why this was so. Let the kids have fun. The compiler has been changed to not report an error in this case. Thus, if the file Main.java contains: ``` void main() { Main main = new Main(); System.out.println(main.message()); } class Main { String message() { return "It works!"; } } ``` everything will work as expected.
17-11-2023
Moving to Approved, with a comment. I tried out the following code with unnamed classes in JDK 21, but not a build of JDK 22 with implicit classes: // Contents of Foo.java static void main(){...} class Foo {...} // Conflict with implicit name for class of the main method? The file is rejected in JDK 21, but the error message could be better. In other words, if any explicitly declared types in the compilation unit and auxiliary classes, rather than nested classes/interfaces in the implicit class, it possible for there to be a conflict between the name of implicit class and an auxiliary class declared in the same file. I think it is fine if such a compilation unit is rejected, but this corner case might be easier to decode with a distinct warning message. (I did not do a build or look at the PR to see if this case is not already tested for.)
17-11-2023
The current thinking of the javadoc team is that if the user wants to have class level javadoc that they should declare the class explicitly. They are willing to reassess this stance based on user feedback. When I thought about it, it seems to me that script writers and those writing in the small would not typically use javadoc but would more likely rely on the script commentary and associated readme/man documentation. Unlike the API of a java library, scripts tend to be a black box and the focus is the function of the script as a whole.
16-11-2023
Not sure javadoc needs to be called out here. javadoc works as expected. Any enhancement to javadoc would come from another JEP. There is currently an ER to investigate how to specify an Implicitly Declared Class javadoc comment. https://bugs.openjdk.org/browse/JDK-8308715
09-11-2023
Moving to Provisional, not Approved. For JEP 463 as a whole, I expect to see some explicit statement on Javadoc support in one or more CSRs before the totality of the CSRs are Finalized. I was surprised the opening of JLS 13.1 "The class or interface must be named by its binary name, which must meet the following constraints:..." didn't include a new bullet on implicit classes in addition to the informative note later in the section.
07-11-2023