Denis, I'm not sure, but javac usage seems to be not our but IDE "problem". No one call javac directly, AFAIK.
So, any --add-exports can be added to wrapping maven, .bat/.sh or IDE settings. I'm pretty sure JB's IDEA will handle this right after Java9 release :) On Wed, Mar 22, 2017 at 12:19 PM, Anton Vinogradov <avinogra...@gridgain.com > wrote: > Denis, > > I'm not sure, but javac usage seems to be not our but IDE "problem". > No one call javac directly, AFAIK. > > So, any --add-exports can be added to wrapping maven, .bat/.sh or IDE > settings. > I'm pretty sure JB's IDEA will handle this right after Java9 release :) > > On Wed, Mar 22, 2017 at 1:43 AM, Denis Magda <dma...@apache.org> wrote: > >> 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? >> >> >> Anton, are you fine with this approach? >> >> — >> Denis >> >> On Mar 21, 2017, at 11:05 AM, 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.Pla >> tformMemoryPool" >> -> "sun.misc.Cleaner (JDK internal API (JDK removed internal API))”; >> >> "org.apache.ignite.internal.util.nio.GridNioServer$Abstrac >> tNioClientWorker" >> -> "sun.misc.Cleaner (JDK internal API (JDK removed internal API))"; >> >> >> "org.apache.ignite.internal.processors.rest.protocols.GridRe >> stProtocolAdapter" >> -> "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 <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 <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 <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/ >> >> >> >
