Also in this document sun.misc.Unsafe - Google Docs there was list of some bunch of APIs and frameworks which will suffer from deprecating of sun.misc.Unsafe . LWJGL and JME also was included in the list.
(it seems LWJGL3 will have not much problem with it as i understand from discussion from the first post)
Will it impact JME ?
(Anyway I am a noob about such things but thought you might find it interesting)
It’s to early to tell at this point. Java 9 was so-posed to come out last December, it missed that date, now we are looking at end of 2016. It will probably miss that date as well. JEP 260 is just a proposal at this point. So far JEP 260 is NOT part of Java 9.
If JEP 260 gets implemented this is how it will happen:
Encapsulate all non-critical internal APIs by default: The modules that define them will not export their packages for outside use. (Access to such APIs will be available, as a last resort, via a command-line flag at both compile time and run time, unless those APIs are revised or removed for other reasons.)
Encapsulate critical internal APIs for which supported replacements exist in JDK 8, in the same manner and with the same last-resort workaround. (A supported replacement is one that is either part of the Java SE 8 standard (i.e., in a java.* or javax.* package) or else JDK-specific and annotated with @jdk.Exported (typically in a com.sun.* or jdk.* package).)
Not encapsulate critical internal APIs for which supported replacements do not exist in JDK 8 and, further, deprecate those which have supported replacements in JDK 9 with the intent to encapsulate them, or possibly even remove them, in JDK 10.
Critical internal APIs for which replacements are introduced in JDK 9 will be deprecated in JDK 9 and either encapsulated or removed in JDK 10.
