Regarding JEP 512

[tzengshinfu]

After mentoring new colleagues transitioning from other languages to Java,
I eventually moved away from the Java ecosystem due to a job rotation. Now,
I primarily use C# (for customer-facing system maintenance) and Python (for
RAG-related SDKs).

I also switched my main IDE from IntelliJ IDEA to VSCode. For small
features or proofs of concept, Python is usually the first thing that comes
to mind. It is usually my go-to—it lets me quickly write the first line of
code and jump straight in. This might also be because IntelliJ IDEA is a
bit heavy, and Java’s syntax and declarations are more complex.
(However, Python can be less reliable, especially with method suggestions.)

Both Python and C# support script-style execution, allowing me to start
coding with just a function definition and evolve into proper
object-oriented classes as needed. But when it comes to system performance
and reliability, I still firmly side with Java.

Although now I can take it easy for a while and no longer need to explain
to new colleagues why string comparisons should use ::equals instead of ==.


/* GET BETTER EVERY DAY */




On Thu, Jun 5, 2025 at 8:25 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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>
> <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/20250608/ea4990ef/attachment.htm>