Fwd: Regarding JEP 512

[Brian Goetz]

This was received on amber-spec-comments.


-------- Forwarded Message --------
Subject: 	Regarding JEP 512
Date: 	Wed, 4 Jun 2025 18:43:32 +0200
From: 	Rufus Riefenstahl <rufusriefenstahl at gmail.com>
To: 	amber-spec-comments at openjdk.org



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-dev/attachments/20250604/d456add1/attachment.htm>