2 ms·

sun.misc.Unsafe has not been removed or blocked, and yes, there's also safe replacements -- VarHandles and the foreign memory API -- for much of its functionali

by pron 6y ago

sun.misc.Unsafe has not been removed or blocked, and yes, there's also safe replacements -- VarHandles and the foreign memory API -- for much of its functionality, which will be removed piecemeal. > I have to hand it to Oracle, this every six months release thing was a brilliant way to squeeze money from customers and absolutely screw over the OSS users and ecosystem in the long run. Huh? How? We've open sourced the entire JDK, making it -- for the first time in Java's 25-year history -- 100% open-source, and we did away with major releases altogether, keeping only the minor ones, and making upgrades cheaper and easier. It's true that some people have not yet internalised what the change means, though. All change is scary, but this one is definitely better for users and for FOSS Java.

AtlasBarfed 6y ago
In my opinion (obviously a downvoted one but whatever), it fundamentally destabilized the whole ecosystem with a massive deluge of near-breaking changes. I get for startups or people running immediate-to-production deployments that it is doable. But Java's ecosystem is boring, staid enterprise, and those people are still running critical systems on Windows XP or worse. IF they are dragging their feet on THAT... The churn basically stuns these people into 1) staying on Java8 for a LONG time, or 2) look at rewriting the system in something else, or 3) scaring them into paying money. I have been doing mostly groovy for the last 10 years so not a single feature in the Java besides invokedynamic (which was really a JVM feature not a Java feature) has impacted me in a good way. Meanwhile... that churn. As a Cassandra user I have seen the "what the hell do we target" conversation play out for 4.0 planning on the dev list, besides the sun.misc stuff. Maybe since (gah AMAZON's Corretto, seriously we have to rely on AMAZON being a good steward of OSS) then the coordination of patching and providing builds has stabilized outside of Oracle offered downloads, but it was a bit unsettling for a while. So while I get that a lot of people see that as "being nimble" and "moving fast", those are precisely NOT what Java has historically been, for better or worse.
- pron 6y ago
  What you're describing is real in some places (Java's ecosystem also includes much/most of Apple, Netflix, Amazon, Google, Twitter, Uber and many others like them), but it is not a result of the new release model. The free support period of JDK 8 ended, like all versions before it, after five years. People who'd want to stay on 8 would have had to pay even if the release model stayed the same. As to the changes, they aren't "near breaking." There have been few breaking spec changes, and they were very small. What breaks is what had always broken code: reliance on internal undocumented classes that change. The reason this happens more now than in the past is not due to spec backward compatibility -- we're as compatible as ever for most intents and purposes -- but because Java was stagnant for a good while, starting with Sun's dying days, and Oracle has been steadily increasing investment in the platform, which means more work done, which means more implementation changes. I think few would say this is a bad thing, but it also means that more code that does what it's warned not to do -- breaks. We're trying to stop this by turning on encapsulation in JDK 16, which would gradually stop libraries from hacking into the JDK and becoming stuck at any specific version.

by pron 6y ago

AtlasBarfed 6y ago

In my opinion (obviously a downvoted one but whatever), it fundamentally destabilized the whole ecosystem with a massive deluge of near-breaking changes. I get for startups or people running immediate-to-production deployments that it is doable. But Java's ecosystem is boring, staid enterprise, and those people are still running critical systems on Windows XP or worse. IF they are dragging their feet on THAT... The churn basically stuns these people into 1) staying on Java8 for a LONG time, or 2) look at rewriting the system in something else, or 3) scaring them into paying money. I have been doing mostly groovy for the last 10 years so not a single feature in the Java besides invokedynamic (which was really a JVM feature not a Java feature) has impacted me in a good way. Meanwhile... that churn. As a Cassandra user I have seen the "what the hell do we target" conversation play out for 4.0 planning on the dev list, besides the sun.misc stuff. Maybe since (gah AMAZON's Corretto, seriously we have to rely on AMAZON being a good steward of OSS) then the coordination of patching and providing builds has stabilized outside of Oracle offered downloads, but it was a bit unsettling for a while. So while I get that a lot of people see that as "being nimble" and "moving fast", those are precisely NOT what Java has historically been, for better or worse.

pron 6y ago
What you're describing is real in some places (Java's ecosystem also includes much/most of Apple, Netflix, Amazon, Google, Twitter, Uber and many others like them), but it is not a result of the new release model. The free support period of JDK 8 ended, like all versions before it, after five years. People who'd want to stay on 8 would have had to pay even if the release model stayed the same. As to the changes, they aren't "near breaking." There have been few breaking spec changes, and they were very small. What breaks is what had always broken code: reliance on internal undocumented classes that change. The reason this happens more now than in the past is not due to spec backward compatibility -- we're as compatible as ever for most intents and purposes -- but because Java was stagnant for a good while, starting with Sun's dying days, and Oracle has been steadily increasing investment in the platform, which means more work done, which means more implementation changes. I think few would say this is a bad thing, but it also means that more code that does what it's warned not to do -- breaks. We're trying to stop this by turning on encapsulation in JDK 16, which would gradually stop libraries from hacking into the JDK and becoming stuck at any specific version.