Denis, I've found that some internal classes like sun.misc.SharedSecrets, sun.misc.URLClassPath, sun.misc.PerfCounter, sun.misc.Cleaner changed their packages. I can create wrapper for this classes with 2 modules, that can be enabled by profiles for java9 and java7-8. For using internal classes that not exported by default, we will need to add new args(--add-exports) when compiling (javac) *and* when running (java ). Is it ok?
Also, there are a two different Unsafe classes in java 9 - sun.misc.Unsafe & jdk.internal.misc.Unsafe, but both of them doesn't have monitorEnter & monitorExit methods, that we use in org.apache.ignite.internal.util.GridUnsafe. What should I do with this case? 2017-03-21 11:21 GMT+03:00 Евгений Журавлев <e.zhuravlev...@gmail.com>: > Denis, > > I found some recommendations on openjdk wiki: > https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > 2017-03-20 20:44 GMT+03:00 Denis Magda <dma...@apache.org>: > >> Referring to your report only the following API was removed completely. >> The rest is still deprecated and stowed in special JDK 9 modules. >> >> >> "org.apache.ignite.internal.processors.hadoop.HadoopClassLoader" -> >> "sun.misc.PerfCounter (JDK internal API (JDK removed internal API))”; >> >> >> "org.apache.ignite.internal.processors.platform.memory.PlatformMemoryPool" >> -> "sun.misc.Cleaner (JDK internal API (JDK removed internal API))”; >> >> >> "org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker" >> -> "sun.misc.Cleaner (JDK internal API (JDK removed internal API))"; >> >> >> "org.apache.ignite.internal.processors.rest.protocols.GridRestProtocolAdapter" >> -> "sun.misc.BASE64Encoder (JDK internal API (JDK removed internal API))”; >> >> "org.apache.ignite.internal.util.IgniteUtils" -> >> "sun.misc.JavaNetAccess (JDK internal API (JDK removed internal API))”; >> >> >> "org.apache.ignite.internal.util.IgniteUtils" -> >> "sun.misc.SharedSecrets (JDK internal API (JDK removed internal API))”; >> >> >> "org.apache.ignite.internal.util.IgniteUtils" -> >> "sun.misc.URLClassPath (JDK internal API (JDK removed internal API))”; >> >> >> >> *Evgeniy*, does Oracle officially suggest replacements for deleted APIs? >> Probably it’s a matter of day to do a switch. >> >> >> — >> Denis >> >> > On Mar 20, 2017, at 9:57 AM, Евгений Журавлев <e.zhuravlev...@gmail.com> >> wrote: >> > >> > Igniters, >> > >> > There are a few JDK internal APIs removed in JDK 9, that we use in >> ignite. We need to decide what to do with these dependencies. Here is a >> list of dependencies after using jdeps >> > >> > 2017-01-26 12:07 GMT+03:00 Anton Vinogradov <avinogra...@gridgain.com >> <mailto:avinogra...@gridgain.com>>: >> > Denis, >> > >> > I've created issue <https://issues.apache.org/jira/browse/IGNITE-4615 < >> https://issues.apache.org/jira/browse/IGNITE-4615>> related >> > to discussion. >> > We have a lot of legacy code inside pom.xml files. One of legacy issues >> is >> > a tools.jar usage. >> > So, it will be nice to fix this as well. >> > >> > On Thu, Jan 26, 2017 at 2:54 AM, Denis Magda <dma...@apache.org >> <mailto:dma...@apache.org>> wrote: >> > >> > > Well, the build fails almost immediately on the latest JDK 9. >> > > >> > > This is the reason (https://issues.jenkins-ci.org >> /browse/JENKINS-25993 <https://issues.jenkins-ci.org/browse/JENKINS-25993 >> >). >> > > >> > > [ERROR] Failed to execute goal on project ignite-tools: Could not >> resolve >> > > dependencies for project org.apache.ignite:ignite-tools >> :jar:2.0.0-SNAPSHOT: >> > > Could not find artifact com.sun:tools:jar:9-ea at specified path >> > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/.. >> /lib/tools.jar >> > > -> [Help 1] >> > > >> > > >> > > If to tweak pom files cleaning out references to tools.jar then other >> > > exceptions arise. >> > > >> > > *Anton V*, could try to build the master on your side applying all the >> > > required changes to pom files? I don’t think I’ll do everything >> correctly. >> > > If the build goes through at least with minor modifications then this >> would >> > > be a good sign. >> > > >> > > — >> > > Denis >> > > >> > > >> > > On Jan 25, 2017, at 3:22 PM, Denis Magda <dma...@apache.org <mailto: >> dma...@apache.org>> wrote: >> > > >> > > Vovan, >> > > >> > > As far as I understand, under the module they mean new >> component/feature >> > > of Java 9 [1]. If you don’t use Java modules then there shouldn’t be >> any >> > > issues at all. >> > > >> > > In any case, let me try to build the project with JDK 9 that has >> passed >> > > feature complete phase. >> > > >> > > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#defining >> -modules <http://openjdk.java.net/projects/jigsaw/spec/sotms/#definin >> g-modules> < >> > > http://openjdk.java.net/projects/jigsaw/spec/sotms/#defining-modules >> <http://openjdk.java.net/projects/jigsaw/spec/sotms/#defining-modules>> >> > > >> > > — >> > > Denis >> > > >> > > On Jan 25, 2017, at 5:47 AM, Vladimir Ozerov <voze...@gridgain.com >> <mailto:voze...@gridgain.com>> wrote: >> > > >> > > Igniters, >> > > >> > > Please see this article [1] from Kotlin guys. They had to re-pack >> public >> > > API because Java 9 doesn't allow several modules to share the same >> public >> > > package. Looks like this limitation could impact us at some point, so >> that >> > > we will not be able to support Java 9 without breaking API changes. >> > > >> > > May be it makes sense to perform some initial investigation of Java 9 >> > > impact before AI 2.0 release, so that we can minimize (or at least >> > > estimate) potential future impact? >> > > >> > > Vladimir. >> > > >> > > [1] >> > > https://blog.jetbrains.com/kotlin/2017/01/kotlin-1-1- < >> https://blog.jetbrains.com/kotlin/2017/01/kotlin-1-1-> >> > > whats-coming-in-the-standard-library/ >> > > >> > > >> > > >> > > >> > >> >> >
