Erik, if I wrote Java that way, I would have starved to death years ago. From your remarks, you do not seem to know all that much about Java. I agree that Java can be verbose and that writing it well requires training, skill, and experience. I would also assert that the training in OOP that most programmers receive it terrible and bears little resemblance to OOP as Alan Kay originally conceived it. It usually takes me a month or more to retrain an average Java programmer after they start working with me. Let's take your major complaints in order.
Let's start with OOP itself. There is nothing wrong with the idea of "objects". An object is merely a definition new data type with its behaviors. There is nothing in the Java language that requires one to write object-oriented code. It is trivially easy to translate a C program into Java (excluding explicit memory management). When I was new to Java programming, I frequently and unintentionally wrote C programs in Java.
Used properly, objects are a powerful programming model (not the only one). Unfortunately, few programmers have the training and discipline to use it well. Their training includes a brief explanation of object-oriented principles, but little help in understanding their purpose or perils. For example, inheritance is a powerful concept that reduces coding and enhances reliability, but only if one understands why, when, and how to use it - --and when not to use it. The "Java Tutorial" and most instruction and coding examples I've seen never really communicate those things effectively. I can remember how awed I was the first time I saw the elegant simplicity of code written by someone who did understand.
Java file I/O looks way too much like C file handling, It is flexible and powerful, but it is arcane and verbose. I do not write it directly without checking myself against the applicable JavaDoc. However, I rarely have to write it because I have a small library of DataStore classes that encapsulate my way of doing I/O from simple print and stream files through relational databases, document databases, Web I/O, streaming queues, and distributed key-value stores. The simple ones take a type and file path or URL to configure and the more complex take a JSON-format specification. Error/Exception handling is built into them. I began the library 20 years ago and I've been updating and adding to it ever since. I've documented it and given it an open source license so it can stay with applications I write for anyone else. By the way, Java has Reader and Writer classes that do simplify I/O. One just has to know about them. The purpose for which I/O classes may be wrapped in other I/O classes seems to be a mystery to you.
Java exception handling can be complicated and confusing if one doesn't understand the concepts and coding conventions. Your specific examples were obsoleted years ago by enhancements to the Java language. If one does understand it, then exception handling becomes part of how one designs applications and it can be a powerful and useful tool. I do not believe that Java exception handling is better or worse that that in any other language that implements error/exception handling. It just is what it is.
Now, let's look as JSON handling. Because I design and build large distributed applications that often move data around networks, I make heavy use of JSON as a message/record format. It is especially useful to me because it is a format native to JavaScript (JavaScript Object Notation) and it also compresses well using the ubiquitous GZIP. Because JSON is so critical to my work I've written a Java library that serializes POJOs (Plain Old Java Objects) to JSON and deserializes JSON to POJOs, all without requiring additional annotations, like Go does. My library contains very little actual code because it sits on top of the open source Jackson JSON Java libraries and uses its already tested JSON handling code.
Modern Java also has "Streams" a more concise and simple way to handle arrays of "things". But you have to learn them to use them. The concepts of controlling access to and the mutability of data, and for managing concurrent processing, are actually at the core of modern programming concepts for reducing program errors and improving program reliability. They are not particularly unique to object-oriented programming.
There's nothing wrong with Go. It's just another language. I've been moving away from writing Java code and starting to use Kotlin, a more modern and concise language that is interoperable with Java classes and can use existing Java libraries. If you haven't looked at it perhaps you should. It's the language that Google has been pushing for Android.
Throwing your own words back at you, you might want to learn what Java can do and why it is in such common use, before you laugh at it. Java can be legitimately criticized for many things, but your specific criticisms merely betray your lack of knowledge of Java and the narrow focus of your experience.
There are reasons why durable programming languages have things like the C “#include” and the Java (or Go) “import”. They make the good solutions of other programmers available to you and me, so we don’t have to reinvent the wheel over and over again. Java has an enormous base of reusable solutions that can be exploited. https://itnext.io/smart-developers-dont-code-2bf882568c37
