And in spite of my distaste for it, I respect that it completely eliminates giant classes of vulnerabilities. You can write bad logic in any language. At least in Java you can't write bad logic that also suffers from memory issues.
And in spite of my distaste for it, I respect that it completely eliminates giant classes of vulnerabilities. You can write bad logic in any language. At least in Java you can't write bad logic that also suffers from memory issues.
Oh you bet you can. There are a number of ways to screw that up.
- memory leaks/loitering is quite common, gc won’t help if your code hangs on to stale refs
- using Unsafe memory can blow up in glorious C++ fashion, directly or indirectly
- using native calls incorrectly can be just as nasty
Now JNI on the other hand, that made up maybe 0.5% back in the day. Not anymore where FFI is the predominant native linkage (but still comparatively quite rare).
(Cue the one weird guy coming out of the woodwork who claims that all of his Java projects in the last 10 years have used Unsafe to great effect.)
Your project may not use it directly, but there’s a pretty good chance one of your libraries does.
There is indeed a difference here between the vast majority taking part in risky behavior and library authors using focused performance improvements. There are a lot more eyes on the library code due to downstream effects than in everyday top-level code.