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

[Reinier Zwitserloot]

 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 do more, you have failed"
> (that's what "doesn't accomplish what it should" 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/20230510/01d23bd6/attachment.htm>