Re: JEP 445 (Unnamed classes): It’s.. still weird (structurally typed).

[Brian Goetz]

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:

abstract class Application {
     private String[] args;

     final void main(String[] args) {
         this.args = args;
     }

     protected int argCount() { return args.length; }
     protected Object arg(int i) { return args[i]; }

     abstract void main();
}

So I think you could characterize this as "not closing the door."


On 5/10/2023 4:35 PM, Reinier Zwitserloot wrote:
> On 10 May 2023 at 22:06:35, Brian Goetz <brian.goetz at oracle.com> wrote:
>> 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." 
>
> 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.
>
> 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:
>
> class $Unnamed extends Application {}
>
>
> 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 
> |public| right now because JEP445 says they don’t have to be, and 
> /solely in light of that/, 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, 
> |main()| doesn’t actually have to be declared |public| (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 /has/ 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.
>
>
> 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.
>
> 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).
>
>> But when you frame the argument as "if you don't domore, you have 
>> failed" (that's what "doesn't accomplish what itshould" means), you 
>> are arguing "let's cancel the project.”
>
> I did say: Does not /fully/ accomplish what it should. I would 
> consider some of JEP445’s goals as failed if |System.out|, misuse of 
> |Scanner| , and the structural typed nature of |main()| 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.
>
>  --Reinier Zwitserloot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230515/e01b68a4/attachment.htm>