Java has problems at present, as I think most people working in the Java ecosystem would admit, and I think that they can be summed up in one word: Oracle.
After releasing Java EE to IBM (well, to the Eclipse consortium officially, but you know …) Oracle has reworked the licensing of Java SE to try to make more money off Java itself. This wouldn’t have been so problematic a decade ago, when open source competition to Java was minimal, but it will have a greater effect with languages such as GoLang, Rust, Julia, Scala, Python etc. eating (admittedly small individually, but significant in total) pieces of the server application development pie. Java is still the best server software platform for most types of applications due to the number, variation and scale of available frameworks and libraries, while the others are languages suited to niche use cases for the most part. And it’s still by far the most used, with only C coming close in terms of usage, and C is primarily used for systems level and embedded applications.
AdoptOpenJDK and others are trying to make moving to OpenJDK as painless as possible, but it’s never totally pain-free with any complex codebase. Simply retesting every code path is a fair amount of work even if nothing overtly breaks. As with many small development companies though we’ve moved to it because paying licensing fees for the language we write in is simply out of the question.
There are many more subtle, but in terms of working in a language, more annoying issues that Oracle is largely responsible for. Deprecating heavily used features because they cost too much to maintain is a big one (I won’t go into detail here, perhaps in another post, but there have been quite a few major deprecations between JDK 8 and JDK 11). Were the features poorly done it would be one thing but deprecating very well-done features due to cost is difficult to stomach, especially when they affect high scale, high performance applications the most.
One of Java’s biggest problems is that the functional interfaces introduced in Java 7 & 8 aren't backed by functional implementations. To be honest, I’m an object programmer first and last, and the current back and forth between object methodologies and functional methodologies doesn't interest me all that much. Lambdas are sometimes convenient, but unless the VM supports them, they’re also slow and difficult to debug. Using immutable objects for functional interfaces only pushes the complexity of maintaining state elsewhere in the application, since if you don’t maintain state somewhere it isn't an application (application == state machine). The reality though is that since developers think functional interfaces are simpler and more efficient, no matter what the actual implementation, there’s a push to use them everywhere possible, and the way that Oracle has implemented them with various hacky javac transformations is a kludge at best.
Hopefully Oracle will clean up their act with Java, or they may find that they no longer set the standard for what Java is. With the way things are going with Java SE, IBM may decide they need to do more than support AdoptOpenJDK and Java EE. The idea that IBM or someone else (SAP among others has their own JDK) might set its own Java standard would have seemed preposterous while Sun was an independent entity, but since Oracle’s takeover of Java’s originator each year it seems less and less preposterous.