3 ms·
It's a) unsafe, and b) an internal, undocumented API. When you start importing from sun.misc.* you've made the conscious (or ignorant) decision to write non-po
by danudey 11y ago
It's a) unsafe, and b) an internal, undocumented API.
When you start importing from sun.misc.* you've made the conscious (or ignorant) decision to write non-portable code which may well break due to any JVM release. It sucks that these people are going to have to update their code (or that end users won't be able to upgrade to Java 9 without adding special command-line flags), but it's not due to fickle Oracle developers, it's due to technical debt that's finally catching up to them.
- kasey_junk 11y agoYou quite simply have NO option to do on the JVM most of the things people are using unsafe for in Java 9/10 without a migration plan from Oracle. What Oracle is close to "hey all you performance sensitive folks, we aren't going to support unsafe anymore, can you tell us what you are using it for and how we can migrate to that explicitly?" It just so happens that one of the leading proposals is "leave in java 9 but make it explicit to turn on". This is probably the right way to do this (in my opinion) but it does have the downside of making neither camp happy (it leaves unsafe so the purists are mad, and it causes headaches for people using unsafe).
- MrBuddyCasino 11y agoWhats wrong with: - deprecate in Java 9 - "make it explicit to turn on" in 10, offer alternative official APIs as fallback - remove entirely when most people have switched
- kasey_junk 11y agoNothing at all. That's what I assume will happen at the end of the day. But people saying that we can just turn it off in 9 because you shouldn't be using internal api's don't seem to get that there is no external solution.
- justthistime_ 11y agoWhy should third-party libraries pay for Oracle's technical debt?
- wtetzner 11y agoIt's not Oracle's technical debt, it's the developers of the third-party libraries that are importing from sun.misc.*.