That is the issue with any guest language, because it is impossible to hide the platform, unless the language is so constrainted that is practically useless.
It is a hard to swallow truth, but guest languages really require understanding of the underlying platform.
Another example, no matter one's opinion on C or JavaScript, mastering them is a much more confortable life on UNIX/POSIX platforms and browsers than trying to pretend they aren't there.
It can also be frustrating if you know a little OO (but not how Java does everything) and then try to learn a functional language that sits on top of one of these OO tar pits of an ecosystem. I can write Python classes, but seeing the complicated mess of Java is frustrating as that has to be learned as well. Nothing against Java btw (it has its place), but it does seem to require a lot of boilerplate.
First off -- I don't really want to get into bickering about Java is OO or not.
That said:
I think that Java is best understood as an enterprise programming language, not as an object-oriented one.
There's a very peculiar class of programming languages that are a product of a specific period of history. At the time, companies were looking for ways to scale beyond the limits of the then-dominant procedural programming paradigm. But they had a lot of existing investment in it, and so teams were naturally hesitant to abandon it entirely.
This situation created an ecological niche that allowed a very peculiar class of programming language to take root. Java and C++ are the best-known examples, but there were others such as Objective-C. C# and Visual Basic.NET are probably the last notable examples. These were multi-paradigm languages that layered object-oriented features on top of procedural bones. Earlier examples such as C++ and Objective-C made this quite explicit, and were likely to even have their atomic types not be objects. Later examples eliminate some features such as non-object types and global functions and variables, but still retain much of their procedural heritage if you know what you're looking for. Probably the most notable one here is a tendency to favor explicitly state-oriented idioms over properly encapsulating state.
Java falls somewhere in the middle. It has later features like full-fledged garbage collection, but lacks others such as a consistently object-oriented type system.
I think that its tendency toward boilerplate directly reflects its stage in this evolution. Basically, what we perceive as boilerplate is really a hold-over from how procedural languages tended to be generally less declarative - it was up to the programmer to handle a lot more stuff for themselves.
I have two remarks here: even if some procedural languages like C seem boiler plate-ish by requiring you to write everything instead of having a platform which offer a high abstractions that has two huge advantages: you are in absolute control and you understand everything from how the bits are layed out in memory and system calls to higher level business logic. So if you need to change something, add a feature, improve performance you know exactly where you have to intervene.
Encapsulating state is very bad on the large scale because you have hidden state in lots of places and you can't argue about what a program does, how it does it and how to modify it. You have to write lots of tests to make sure things won't broke.
In some very large OOP codebases adding features or fixing bugs becomes a nightmare. Every small change you make will break hundreds of tests and while you fix the code to pass those, you will break other tests. Thing that can take days at most in sane codebases might take weeks.
I would argue that, if the scope of impact on a change is that large, then, by definition, you have not encapsulated your implementation.
(That, or you should not have made the change that way in the first place. Much like best practices for API changes involve shipping a new version in parallel and then slowly migrating everything over to it, a breaking change to the behavior of a class that really does have a legitimate reason to be used pervasively - say, a collection - shouldn't be done by just suddenly breaking all the code that uses it.)
Which speaks to exactly the distinction I'm trying to draw when I say, "a tendency to favor explicitly state-oriented idioms over properly encapsulating state." Note that simply sticking getters and setters on your state is not the same thing as encapsulating it.
It's kind of hard to explain the difference except by example, so I'm not really prepared to dive into it here. To be honest, I think the best way to get a feel for it is to read and understand the source code of an early Smalltalk system. Smalltalk-80 is small enough that one can get a decent feel for how everything works in an evening or two.
Then a C compiler optimizer decides that knows better and changes the table underneath, or maybe it doesn't but the Intel microcode unit decides to write the Assembly instructions in unexpected way.
Or that spot we were 100% certain was a bottleneck as it clearly wasn't micro-optimized C code, shows 0.1% hit on the V-Tune profiler.
It is a hard to swallow truth, but guest languages really require understanding of the underlying platform.
Another example, no matter one's opinion on C or JavaScript, mastering them is a much more confortable life on UNIX/POSIX platforms and browsers than trying to pretend they aren't there.