3 ms·

Sun.misc.Unsafe is still available and equivalent _safe_ functionality is being introduced before it is removed.and, most reflection stuff can be done public an

Sun.misc.Unsafe is still available and equivalent _safe_ functionality is being introduced before it is removed.and, most reflection stuff can be done public ancestors with a little care. Yes, this will cause some issues initially but I have hunk it's a good move for Java in the long term.

lvh 9y ago
You mention Java again; so I'll mention JRuby and Clojure again. "It will cause some issues" is a serious understatement, and this is a clear violation of the (social) contract the JVM had. Enterprises use Java in no small part because they don't randomly break the billions of lines of Java code out there. s.m.U is a perfect example: they've wanted to break it for a while but aren't doing it until they can actually replace it. A lot more software is broken by Jigsaw than would've been broken if s.m.U went away. Plus: there's an escape hatch: for better or worse, if s.m.U went away, you'd start seeing a whole ton more JNI.
- mike_hearn 9y ago
  It sounds a lot like the issues Clojure has with Java 9 are to do with rather non-obvious assumptions it made about how the JVM works that are now broken. For instance, Leinigen putting itself on the boot classpath to get faster startup time is really a hack to work around the problem that Clojure apps do way too much stuff at startup and generates very old bytecode forms that takes a lot of work to verify. If you want to disable bytecode verification for Clojure apps you could just use -verify:none instead of blaming Java 9 for changing the way things are loaded at startup, which has never been a guaranteed property of the platform. Lots of complex apps and language runtimes have been making assumptions about things that were never guaranteed or even documented and will need adjustment in Java 9, but that's OK - the prior situation was never sustainable and a big part of why Java 9 is taking so long and is such a big effort is to get the ecosystem onto a more sustainable, supported footing. Creating supported replacements for Unsafe stuff is one such example but there are plenty of others.

lvh 9y ago

You mention Java again; so I'll mention JRuby and Clojure again. "It will cause some issues" is a serious understatement, and this is a clear violation of the (social) contract the JVM had. Enterprises use Java in no small part because they don't randomly break the billions of lines of Java code out there. s.m.U is a perfect example: they've wanted to break it for a while but aren't doing it until they can actually replace it. A lot more software is broken by Jigsaw than would've been broken if s.m.U went away. Plus: there's an escape hatch: for better or worse, if s.m.U went away, you'd start seeing a whole ton more JNI.

mike_hearn 9y ago
It sounds a lot like the issues Clojure has with Java 9 are to do with rather non-obvious assumptions it made about how the JVM works that are now broken. For instance, Leinigen putting itself on the boot classpath to get faster startup time is really a hack to work around the problem that Clojure apps do way too much stuff at startup and generates very old bytecode forms that takes a lot of work to verify. If you want to disable bytecode verification for Clojure apps you could just use -verify:none instead of blaming Java 9 for changing the way things are loaded at startup, which has never been a guaranteed property of the platform. Lots of complex apps and language runtimes have been making assumptions about things that were never guaranteed or even documented and will need adjustment in Java 9, but that's OK - the prior situation was never sustainable and a big part of why Java 9 is taking so long and is such a big effort is to get the ecosystem onto a more sustainable, supported footing. Creating supported replacements for Unsafe stuff is one such example but there are plenty of others.