Hi there Dick, I was curious of what you would think since I know you do Java and is big on OOP.

No, I don't do Java on a regular basis anymore.

But I believe I made it quite clear in my writing that I don't consider myself a Java expert. This is written from a beginners perspective, which IMHO has its own value. I clarify that here: https://erik-engheim.medium.com/but-i-dont-write-java-that-way-4f38d01c7ae7

Also I made pains in my story to point out that I don't consider OOP all bad, but my point was that the kind of OO that the Java community has been pushing overdoing it to the point of making it harmful.

I know you can write C style Java, because I used to correct Java student assignements some 20 years ago, doing just that. Although I would argue Java isn't a very good language for procedural programming.

I hope you don't mind me pushing back a bit on your argumentation. I got a lot of respect for you and your skills, even if I am a pretty opinionated guy. I don't think you get anywhere in life if you are not ready to question even what experts say. I remember debating my University professor who was an expert on concurrency for two hours once. In the end, he had to admit that I was actually right and he had misunderstood a core concept in our text book.

My argument is that the Java communit IS Java. The common practice of Java and how the standard libraries are designed is part of the Java experience. You cannot divorce the two. While you may write a superior IO library, it doesn't change the fact that the Java standard library follows a very 90s style OOP. What I would deem an approach which is a product of overhyping and overusing the OO paradigm. This is the tradition you become part of when you pick up Java.

Google around and look at the advice you find. Listen to what lots of Java developers say. Part of me writing these latest stories has been because I have been rather shocked that so many Java developers are still stuck in 1990s style OOP thinking. Like they haven't picked up on the directional change the last 10-15 years where OO has been toned down and we have accepted that it is not always the best solution and sometimes other paradigms are good to complement our solutions.

I know that Java has a Reader and Writer class, but in my opinion they don't solve any of the problems I presented.

Wrapping of IO classes is not a mystery to me. As I pointed out, that is sometimes necessary even in Go. My objection to Java is how they always use wrapping, when free functions would have been a better choice.

As for exception handling. You cannot brush this off with "if you don't understand the concepts." If there was not a clear problem with how Java does this then JDK 8 would not have added the concept of closable objects. The very problem I described was real enough that the Java designer added a feature to the language to solve it.

And the point about my argument was not really about Java being worse, even though that is my personal opinion. Rather it was about how Java developers frequently dunk on the Go approach and call it inferior. Clearly in these cases I showed, Go offers an equally good or better solution.

On the topic of JSON. I am fully aware of that you can write better JSON libraries in Java. This applies to almost any language. Anything in a standard library that sucks, could in principle be wrapped in something nicer. The point is to show what is the most common approach. In my code examples I always try to stick to standard library solutions as that is what people will tend to learn first. Java has no JSON handling in the standard library. A major oversight IMHO. So I used whatever appeared most common.

I don't think Java Streams is really relevant in this discussion about abstractions over IO functionality. Java Streams is what one would call a sequence or a list in another programming language. And frankly here Java is rather late to the game. This is a pretty old concept that functional programmers have used for decades.

I do think Kotlin is a nice update, and that is of course one of the advantages of the JVM. You can add a new language and keep using your old Java code. I think what surprises me is how slowly Kotlin has been embraced given that it seems like a language which is so much cleaner and made for modern times than Java.

I considered learning it back when I was doing iOS and Android development. Because Swift and Kotlin are very similar languages it would have made the mental switch between the platforms much smaller. Independently Kotlin is not all that interesting to me. It was only interesting in the sense that it looked a lot like Swift. And I guess I wish for its success as that would make more people ready for Swift. For Java developers switching to Objective-C used to be a major mental bridge to cross. Going from Kotlin to Swift would be very small transition as far as I can tell.

And no, I don't plan on learning Java in detail. You got to understand the motivation for my writing as I explain here: https://erik-engheim.medium.com/but-i-dont-write-java-that-way-4f38d01c7ae7

I wrote some of these last articles as part of learning Go better. Throught this process I encounter many arguments from Java and C# developers on why their favorite language of choice is better. You would get the classic condesending argument that Go is just for small toy programs because it doesn't support "real" OOP like Java.

Thus I was inspired to investigate how well this "real" OO faired against the Go approach. I don't think that put Java in a favorable light.

If Java developers think I am using the language wrong, then I think it is on them to disprove my point. I will not be making the case for them. My interest isn't Java. It is Go.

One of my key interests in in user experiene and that is something I write about. A very important concept in UX design is to reduce the number of choices the user is given to improve usability. Java may have reached a point where the plethora of choices become so large that it slows down developers.

There is a sweet spot. Too little existing functionality and you are forced to reinvent the wheel. Too much functionality and you get lost in a maze of choices.

This can be hard to spot if you have done Java for 20 years. That is why a beginners perspective is a valuable addition.