JEP 445: Unnamed Classes and Instance Main Methods - don not move forward!

[Aaron Scott-Boddendijk]

 To provide another perspective that doesn't come from anyone inside the
JDK development process or affiliated with any organisation that is.

I have been in professional software development for 30 years. While I am
not involved formally in education, I do 'give back' by involving myself in
several active Java communities. For students new to programming, this is a
mix of self-guided individuals (or misleadingly guided - youtube is filled
with some terrible material), or lost-at-sea secondary and tertiary course
students (you may not see all those in your courses that are struggling,
and may not be the sole source of education on the topic).

I have also followed, in depth, the initial discussions of the features in
this JEP from early inception, through the JEP's evolution to its current
preview state.

There are two things this JEP addresses. One is directly for the student,
shrinking their learning load, and the second is one of mind-share.

If the initial experience is not simplified then students with a choice
will engage with other languages first and educators will increasingly
pivot away from Java to languages that present an easier first experience.

That initial experience is filled with complexities such as the
static/non-static distinction, the ceremonies of declaring a class (even
the minor matter of matching, case-sensitively, the public class name to
the filename) or, as your posting focuses on, the complexity of the
entry-point declaration.

Oft-used mantras such as "just ignore this bit for now" or "just copy this
and ignore the stuff above and below" don't truly lift the cognitive burden
from the students as well as we'd hope. With the frequency of students
struggling with the initial experience, educators have to accept that it is
human nature to either dwell on these details or be impacted by the
distraction of reading around them. Removing the need for them does have
some merit to early learning.

I should note that I was initially negative towards this JEP myself. I had
concerns that it was attempting to overfit the initial engagement
experience to the detriment of later learning progression. This is seen
often in libraries and frameworks that tune a part of their API to present
a more elegant, but eventually irrelevant, hello-world case - an
increasingly common "please pick me" marketing ploy for a system component
that should be selected on long-term merits, not initial gut-feelings.

However, having been involved (largely as an observer) in the evolution of
these changes, I can say that the discussion has been robust. Several
proposals were rejected or revisited specifically because, while they would
make an even simpler first step, they would add new burdens to progression.
I no longer feel that this is an irresponsible or detracting change.

As a developer with some projects heavily invested in Java, it is good to
see that Oracle and others are investing significant effort in a large
number of very high-value features (the JVM Language Summit shows off a
number of them). These look likely to ensure the platform remains relevant,
even regaining ground in a world that has shifted, changing how and where
Java is deployed. But that effort will only be valuable if new developers
continue to learn Java in the first place - I think this JEP does go some
way to addressing that.


On Sat, Sep 16, 2023 at 5:40 AM Arne Styve <arne.styve at ntnu.no> wrote:

> I recently came across this JEP, and was very surprised. Why on earth
> should you add features to a professional programming language just to
> apparently make it a bit easier for students and beginners to learn to
> code? And especially when the suggested feature has no real use (and cannot
> be used) once you learn to program OOP properly?
>
>
>
> I’ve been a SW-developer and manager for more than 20 years, and a teacher
> of OOP at University for 15 years, and have never, ever experienced that
> the public static void main(String[] args) have been remotely problematic
> for students in learning to program.
>
>
>
> Please have this JEP terminated.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230916/0d826b71/attachment.htm>