On 9/29/2022 3:07 AM, Tagir Valeev wrote:
## Unnamed classes ... Such source files can still have fields, methods, and even nested classes, so that as a program evolves from a few statements to needing some ancillary state or helper methods, these can be factored out of the `main` method while stillI wonder how we tell apart unnamed class syntax and normal class syntax. E.g., consider the source file: // Hello.java public class Hello { // tons of logic } void main() { } Will it be considered as a correct Java file, having Hello class as a nested class of top-level unnamed class? If yes, then, adding a main method after the class declaration, I change the class semantics, making it an inner class. This looks like action at a distance and may cause confusion. E.g., I just wrote a main() method outside of Hello class instead of inside, and boom, now Hello is not resolvable from other classes, for no apparent reason.
Yes, this is where the bodies are buried. At some point, the file name is likely to come into play, even though we would prefer it not. (Note that we have a little of that issue with "auxilliary classes" today.) I think the move here is that for unnamed classes, if there is a "top level" nested class that matches the file name, we call that an error.
I assume that the main() method is required for an unnamed class, and if there are only other top-level declarations, then it should be a compilation error, right?
Probably so, yes.
## Predefined static imports ``` void main() { println("Hello World"); } ```I wonder how it will play with existing static star imports. We already saw problems when updated to Java 9 or Java 14 that star-imported class named Module or Record becomes unresolvable. If existing code already imports static method named println from somewhere, will this code become invalid?
"Star" is the right word. Currently we have a scheme where single imports and beat star imports, so that if someone declares their own `println` method, it wins. Details to be worked out.
