Man, I'm sort of with you. In the last few years, I've spent time in a variety of languages --- Python, Ruby, JS, Java, and lately Go and Haskell --- and Java just seemed completely terrible: bureaucratic, staid, and just plain mediocre by many standards.
Then I started reading a lot of C++. And I mean no disrespect to the many brilliant people who use and enjoy C++, but it wasn't until then that I really got why Java exists.
Yeah. And as above I'm kinda sorta with you. People tend to criticize Go along similar lines, that it's not particularly innovative, and my reaction is similar. It's not meant to make you look smart or blow your socks off or whatever; it's meant to help you be productive in no small part by being very, very straightforward.
As such, I'd actually criticize Java for not being simple enough. It's well and good to be staid, but excessive bureaucracy is problematic. Arrays are thoroughly un-idiomatic in Java. Exceptions play hell with attempts at control-flow analysis. Lack of type inference increases repetition. The language is embarrassingly devoid of literals. Pick your poison, really.
And people should feel free to disagree, but I don't think such as type inference, literals, or multiple return values are anything particularly flashy. If anything, they tend to make code simpler and/or cleaner.
No particular section, it's the entirety of what the book shows that's remarkable: "This book presents the results of Project Oberon, namely an entire software environment for a modern workstation. The project was undertaken by the authors in the years 1986-89, and its primary goal was to design and implement an entire system from scratch, and to structure it in such a way that it can be described, explained, and understood as a whole. In order to become confronted with all aspects, problems, design decisions and details, the authors not only conceived but also programmed the entire system described in this book, and more."
Also, if you think that JVMs and JIT'ing compilers are cool, take a look at Michael Franz's PhD thesis at ETHZ: "Code-Generation On-the-Fly
A technique for representing programs abstractly and independently of the eventual target architecture is presented that yields a file representation twice as compact as machine code for a CISC processor. It forms the basis of an implementation, in which the process of code generation is deferred until the time of loading. At that point, native code is created on-the-fly by a code-generating loader. The process of loading with dynamic code-generation is so fast that it requires little more time than the input of equivalent native code from a disk storage medium."
I think I see what you're saying. And that actually sounds right up my alley, truth be told. That characterization reminds me a little bit of Plan9.
I say it's up my alley because lately I've been paying particular attention to folks like Rob Pike and Rich Hickey. (I'm sure there are more.) I am not sure they'd agree with this characterization, but they're both part of a movement to simplify programming, especially by cutting out excess and complexity.
Go is an example of a more straightforward, modern C, complete with strong concurrency primitives, first class functions, duck-typed interfaces, abundant literals, etc. I'm still learning about Clojure but I started looking at it after watching Simple Made Easy and The Value of Values, both of which espouse a somewhat different form of simplicity. Still, I think it's animated by a similar line of thinking, that we as a profession are hurting ourselves unduly by building so many systems we struggle to understand and/or maintain, and one way in which we do it is through both the technology we use and the way in which we use it.
The JVM/JIT bit might go over my head, but I'll be sure to check that out, as well.
Then I started reading a lot of C++. And I mean no disrespect to the many brilliant people who use and enjoy C++, but it wasn't until then that I really got why Java exists.