IMO: 1) sun.misc.PerfCounter usages must be removed 2) sun.misc.Cleaner - either remove, try to switch to DirectByteBuffer or Unsafe.allocateMemory() if possible, or create a wrapper delegating to official Cleaner from Java9. 3) sun.misc.URLClassPath and sun.misc.SharedSecrets - used only in one method, try remove of refactor it if possible. 4) monitorEnter and monitorExit are used only in one place in ATOMIC cache. This place should be refactored.
On Tue, Mar 21, 2017 at 9:05 PM, Evgenii Zhuravlev <e.zhuravlev...@gmail.com > wrote: > 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/ > >> > > > >> > > > >> > > > >> > > > >> > > >> > >> > > >
