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've been using G1 for quite a long now and it doesn't do a major stop the world GC, unless in some very extreme theoretical situations I've never encountered yet. However sub-10-millisecond pause targets are still a challenge, but there is a lot of progress in this area still being made.
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.
Thinking about 'us' is definitely the best thing to do and it is definitely a failing of (some) young but talented programmers to develop a certain arrogance which only puts others off.
However, at some point it will become obvious that you can/can't effect change in a meaningful timeframe. And if the latter, you should move on.
The sad truth is that often the bad type of programmers the author describes are unwilling to learn, and are especially reluctant to take lessons from a new/young colleague.
it's easier to just quit and look for a better job. it's the engineer's solution. what you suggest is a challenge to improve your soft skills. it's probably worth it but it's not for everyone.
I think a compromise is more constructive: fix as much as you can in a given period, and then find a better job. Apparently a 4 month programming stint doesn't lookt that good in a CV.
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.
