Correct. But apparently when coupling abstractions with concurrency the threats are not immediately obvious and one will learn only after encountering bugs like this ...
It actually does remove a lot of hassle from developers. But with every abstraction, the complexity is not actually removed, just hidden. This means that in situations where the abstraction fails, you would need to still understand the hidden complexity ...
The GC pauses locking entire JVM for several seconds are indeed a concern for many application classes, financial exchanges included. Exactly for this purpose even designated JVMs are built, Azul for example is providing a pauseless JVM which is able to handle the garbage collection concurrently. Or if the JVM migration itself is not possible, other solutions, such as tuning the application to avoid Full GC entirely or using off-heap allocations for big data structures are used.
I guess the tooling in this case is about as good as it gets - independent of the tools used, writing Java EE "by the spec" has traditionally been painful independent of the IDE used.
The minute you stop thinking about "they" and start thinking about "us", there is a chance. If you just walk around thinking and knowing things are sour but are not going to do anything about it - guess what. Nothing is going to change. But if you take the lead, sell your ideas, execute upon the change, you will see daylight one day.
Most engineers never exit the "whining" phase though. But those who do, make a truly good mate to work with.
That is indeed our experience as well. Going beyond 8-12GB of heap starts to produce all kind of weird side effects. So our best recommendation is to scale vertically on the heap size ...
Congrats! You were the first one to spot the easter egg we planted, if you contact us referring to your original comment you can have the Plumbr for free for one year.
Apologies for the confusion. The aim was to demonstrate that against our expectations the typical heaps in JVM landscape are not set that high and ~25% of the apps are doing just fine with less than 256MB of memory allocated.
And another aspect we wished to demonstrate was the sheer size of permanent generation on some of the applications. I have yet to face a leak-free app where permgen > 256MB seems justified ...
That is indeed the case - both players in this match were not careful. We are open about our shortcomings and also think that the other player was not too careful to say the least ...