Eventually now it’s time to put all the doubts aside on when Ignite should support JDK 9. The JDK is production ready and was released not long time ago.
Is there anyone interested to enable JDK 9 for Ignite? — Denis > On Mar 24, 2017, at 10:22 AM, Denis Magda <dma...@apache.org> wrote: > > Evgenii, > > Thanks for the investigation. Could you update the ticket with all of your > findings and suggestions? > > If you feel you can’t fix it by 2.0 then let’s do it in the next minor > release like 2.x. I don’t think that we introduce any breaking > compatibilities when JDK 9 support is added later. Do you think so as well? > > — > Denis > >> On Mar 24, 2017, at 9:24 AM, Evgenii Zhuravlev <e.zhuravlev...@gmail.com> >> wrote: >> >> Igniters, >> >> I found that maven-war-plugin, that used in ignite-websphere-test doesn't >> work with java 9. Here is issue: >> https://issues.apache.org/jira/browse/MWAR-397.They have workaround with >> setting MAVEN_OPTS, but this workaround doesn't fit us. >> >> 2017-03-24 0:51 GMT+03:00 zixu mo <hufeng1...@gmail.com>: >> >>> >>> >>> JB IDEA2017.1 released, support jdk 9. >>> >>> >>> >>> >>> On Fri, Mar 24, 2017 at 12:14 AM +0800, "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 12:19 PM, Anton Vinogradov 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 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 >>>>> 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 Евгений Журавлев : >>>>> >>>>> 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 : >>>>> >>>>> 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, Евгений Журавлев >>>>> >>>>> 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 > >>>>>>> : >>>>> >>>>> Denis, >>>>> >>>>> I've created issue > >>>>> 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 > >>>>>>> wrote: >>>>> >>>>> >>>>> Well, the build fails almost immediately on the latest JDK 9. >>>>> >>>>> This is the reason (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>> 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 > g-modules> < >>>>> >>>>> http://openjdk.java.net/projects/jigsaw/spec/sotms/#defining-modules >>>>> >>>>>> >>>>> >>>>> >>>>> — >>>>> Denis >>>>> >>>>> On Jan 25, 2017, at 5:47 AM, Vladimir Ozerov > >>>>>>> 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/ >>>>> >>>>> >>>>> >>>> >>> >>> >>> >>> >>> >>> >
