From my perspective, a lot of the problems listed above are either because 'you're doing it wrong' (and awful excuse that could apply to any language) or are hangovers from previous Java versions. That said, I've addressed a few of your points from my own personal experience working with Java for the last 6 years (3 years professionally):

> - the use of the Object type (surprisingly common)

Doesn't appear common to me at all - the code base I work on has no declaration of anything as 'Object' anywhere in well over 300k lines. None of the 3rd-party libraries we use have the Object type in any of their public APIs. So from my experience this is a non issue, and I'm quite surprised it was mentioned. Then again, I do work on a relatively new (<4 yrs old) code base, recently moved to Java v1.8.

In fact, probably the biggest offender of Object use is the Java built-in libraries, especially the Collections framework, parts of which are frustratingly not type-safe as a compatibility hangover from before generics were introduced. For a fun example, the map interface has put(K, V), but get(Object). Grrr!

> - Need for frequent casting is both inelegant and a big source of error

Again, the code base I work on has very little casting. I feel like this is more a symptom of how code has been designed rather than an inherent issue with the language. Once more possibly a hang-over from the pre-generics days.

> - Classes are giant, heavyweight and deeply stateful, and tend to have deeply nested hierarchies

This seems a bit subjective, so I'd say you might be writing/using classes badly. How does Java differ from any other OO language in this respect? And remember the words of The Great Joshua Bloch: always favour composition over inheritance!

> - Class-scoped variable names (E.g. That don't require explicit 'this') are confusing, and for example don't make it clear whether a variable being referenced is a class variable, instance variable or local variable. Creating inner classes complicates things further, and inherited variables and methods are also opaque

A moot point when using a modern IDE as far as I see it. But certainly a concern if syntax highlighting isn't available.

> - creation of new types is a pain which promotes overuse of primitives (ints/strings/bools) over more expressive and safe types

How/why exactly is this a pain? Related to the verboseness, perhaps? And certainly in the code I work on I wouldn't consider primitives over-used at all. Don't forget the Java enum, one of the best features of the language, can quickly be put together and contain as much extra information/functionality as you'd like. We certainly use them frequently.

> - null pointers are rampant, and even considered idiomatic, for example during initialization

If null pointers are this rampant, then again the code must be badly designed or doing something wrong. Null pointers are probably the least common issue we get in our code base. Of course I can only speak for myself. The Optional in Scala does sound like a brilliant feature, but doesn't demonstrate why Java is any worse than other non-Scala OO languages (here's looking at you C#).

> - imperative style is forced on the user in a very strong way; for example no literals for array lists, maps etc, standard library overwhelmingly provides mutable data structures

I can't argue with this. Mutibility in the standard libraries isn't great and parts of it certainly could do with a re-write (which worked out totally fine for Python, amiright?) and generally there are few few 'correct' ways to write anything (I'm ignoring the monstrosity that is Java EE here).

But this is an aspect of the language I actually really like. I like the verboseness, I like the lack of ambiguity, and I like that all well-written Java code looks remarkably similar. If dev teams enforce strict (and at least partially arbitrary) style rules, what's wrong with the language doing it for you? If you think that's a bad thing then I'd be very interested to hear your reasoning.