AFAIK there aren't other ways to get the performance required to be competitive in the financial space. People that are using these libraries don't want to use

AFAIK there aren't other ways to get the performance required to be competitive in the financial space. People that are using these libraries don't want to use undocumented, Unsafe code. However, their hands are forced given the races they are competing in. They could switch to C++ but that's not really a great option for firms that have java code bases going back 10+ years. Plus, personally, and for a lot of others, the jvm plus a dash of sun.misc.Unsafe, is a lot better than going over to C++. More concretely, Here are two sets of trading libraries that use unsafe for direct memory access: https://github.com/real-logic/simple-binary-encoding https://github.com/real-logic/simple-binary-encoding https://github.com/OpenHFT https://github.com/OpenHFT (various libraries in here use it, once you drink the Unsafe Kool-aid it's hard to turn back from the performance benefits you obtain). If Oracle just rips off the Unsafe band-aid without a replacement, the business decision for these firms is still sound. They will just stay on 8 and start making migration plans (likely to the C++ bandwagon). However, It sounds like Oracle plans to give a sane alternative which is good and what everyone using Unsafe would prefer (along with deprecating it the meantime to give them some time to adapt). One real world example: The CME (Chicago Mercantile Exchange) reworked the entire way they distributed market data (v3 of their Market Data Protocol) to mirror the cutting edge in performance oriented serialization libraries (e.g. Cap'n Proto). They also commissioned an Open Source library for parsing that data (real-logic SBE), it uses unsafe to approach the performance of C++ code.