SOLID is generally speaking a good idea. In practice, you have to know when to apply it.
it sounds like your main beef in Java is the need to create interfaces for every class. This is almost certainly over-engineering it, especially if you are not using dependency inversion. IMHO, that is the main point of SOLID. For the most part your inversions need interfaces, and that allows you create simple, performant unit tests.
You also mention OOP - It has it’s place, but I would also suggest you look at functional programming, too. IMHO, OOP should be used sparingly as it creates it’s own form of coupling - especially if you use “Base” classes to share functionality. Such classes should usually be approached using Composition. Put this another way, in a mature project, if you have to add a feature and cannot do this without reusing a large portion of the existing code without modifications you have a code-smell.
To give you an example, I joined a company about a year ago that coded they way you are describing. Since I joined, we’ve been able to move towards a more functional approach. Our code is now significantly smaller, has gone from about 2% to 60% unit testable and our velocity is way faster. I’d also suggest that for most companies, this is what they want not what they currently have. There are far too many legacy projects out there.
So, yes - I very much agree with SOLID but like anything it’s a guideline. My suggestion is learn how to refactor towards more functional patterns.
True… I personally dislike Java and work mostly in Kotlin these days.