Regarding JEP 512

[Rufus Riefenstahl]

Hello there, project Amber EG team.
 I would like to share my honest thoughts regarding JEP 512: "Compact
Source Files and Instance Main Methods".
First off, let me introduce myself. My name is Rufus Riefenstahl.
I have been programming Java for about 20 years, 13 of them professionally.
My work includes major contributions to desktop software at film production
firms and 3 years so far, backend development using Spring Boot. Lately I
am preparing to apply for a mentorship position at my company, teaching
novices how to do Java better.
Now my thoughts about the JEP...
When I first saw it, I thought to myself: "Well, great! Newcomers can get
started with Java quicker!"
Yes, the "public static void main(String[] args)..." is definitely a lot to
a new coder, especially if not proficient enough in object orientation, and
seemingly very difficult for a person whose first programming language is
Java! (I remember it myself...)
As the JEP depicts, a beginner may tell to himself that the language is
just too "complex" to carry out a simple println(). Also, it says that the
current, long way of doing it, is intended for large scale programs. And
that's where my first doubt about this arrives - what really is a "large
scale program"? Onto that later. The JEP proposes an interesting way of
simplifying things. Instead beginners, or "simple command line
scripts/utilities" (!!!, I will get to this later too) will use the void
main(){} with IO.[whatever]. Now here is the second problem as I see it: By
introducing an "IO" class, the "conventional" ways of getting something to
the standard input/output increases to 2. The original is
System.out.println(), which is the standard, Java-iconic way to do it. Now,
IO is not limited to this "compact notation" as I will call it, but freely
available in "large-scale programs", too. This may eventually result to
some people using IO for printing & reading in non-small source. But I
still presume most codebases will continue to use
System.[whatever].[whatever] or the BufferedReader to get input - most Java
is written in enterprise anyway. (yes, getting input, especially in Java,
is pretty complex for a beginner, for sure.). Also tutorials regarding Java
have always used the "standard" ways and it would take time to adopt this
simplification and would maybe contribute to some confusion on why don't
people introduce Java "that way". Another thing is that most
"production-grade" Java isn't on the newest version, which is unfortunate,
but this JEP being integrated to 25, an LTS, would make a difference. Back
to my criticism. This creates a duality. Why may this be this be a problem?
Let me explain. The core values of Java.
Most of the Java community, or at least the contributors/developers working
on it, value stability, backwards compatibility, and overall maybe a slower
pace of features, but making sure that those features actually commit to
making Java better. To make Java last very long as a language. A language
you can always come back to and not get overwhelmed with a bunch of
"optional" syntax candy. I stand behind this too. Trust me, I have
programmed in languages like C#, and their pace of change is too quick for
me - while reading other projects' code I need to have a documentation tab
open - showing the new syntax, at least most of the time. Java strives to
be different. Recent additions like Virtual Threads prove that Java is
exceptional: amazing "async/await" behaviour without the "burden" of
function coloring (I recommend reading the post "What color is your
function?" online). Making Java great, maintainable, good to write for the
future, while being familiar to any programmers that may return to Java.
Can't of course forget the new people, too. Sure, Java onboarding is not
the easiest, especially when compared to languages like Python, but it
makes sense in the long run.
This gets to the core of this message: The feature that's being proposed
isn't inherently "bad", but the philosophy change that may occur. For
example, specifically dividing "small learning programs/utilities" and
"large scale programs" is just completely foreign to me in the Java space.
Java was always built on solid conventions, style guides, and the ease of
writing (not immediately perhaps, but after understanding major OO
concepts), and most importantly - reading, yes, reading. When I open a java
project of any codebase, I can understand it almost always. Don't forget:
most time looking at the editor buffer is spent reading and debugging code,
not writing new code. Yes, the programming landscape is changing with
Python at the top of the food chain currently. Java must adapt to necessary
industry changes, but should not adopt the "shiny new thing" immediately,
as it hasn't done in the past and I feel like that's a good thing. Again, I
don't feel like this compact writing is bad, but I feel that it's not
absolutely necessary and contributes to a code style divide, more so
because it's not only geared towards beginners but also "small scale
programs". Java has gotten lots of "hate" from a lot of people who
criticized things I praise. Java isn't perfect, but it's a stable,
statically typed high-level programming language. A language you can always
get back to.
I'm sorry if this "rant" was too long, but these are my thoughts. Perhaps I
can't do much now as the feature is looking like to be 100% integrated in
25, but I at least so that this message to serves to everyone as a some
sort of a "cautionary tale".
If you don't agree with my opinions, fine. But be aware.
If you'd like to discuss this matter further with me, I am 100% open.

Have a blessed day.
- Riefenstahl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-comments/attachments/20250604/04393709/attachment-0001.htm>