Regarding JEP 512

Thu Jun 5 15:01:54 UTC 2025

That was an interesting perspective from Rufus. I was just about to write to this mailing list about how I was disappointed that it was now necessary to write IO.println rather than just println.

My perspective comes from teaching Java. I have always felt that learning a language involves evolution. Java has been reluctant to follow this model by requiring full on OOP on day one with all the myriad ‘decorations’. I was excited to see ‘void main()’. It made the entry point simple. Classless or simple source file was another enhancement that I also felt was going to make Java a language that could be taught, not just at University, at Primary and Secondary schools. It may be too late for this as Python has pretty much taken over the public-school space.

As for println or as it is now named IO.println, it is another significant advance in making Java easier to learn. I think we can agree that console I/O beyond learning language fundamentals is over, done, and nailed to its perch (Monty Python reference). Therefore, any simplification is significant. You want a desktop UI then use JavaFX. As I mentioned, I’m not crazy about needing the prefix IO but it is still better than System.out.println. I never taught System.in other than as a parameter for the Scanner class.

Enhancements to Java that, as Brian has called it as paving the on-ramp, must be applauded and encouraged. We may not agree (I still don’t like requiring IO) but it shows that the language can evolve not only to meet the needs of senior developers but also new developers and children.

Ken Fogel

From: amber-dev <amber-dev-retn at openjdk.org> On Behalf Of Brian Goetz
Sent: June 4, 2025 6:28 PM
To: amber-dev <amber-dev at openjdk.java.net>
Subject: Fwd: Regarding JEP 512

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><mailto:rufusriefenstahl at gmail.com>
To:
amber-spec-comments at openjdk.org<mailto: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/20250605/05ecdecf/attachment-0001.htm>