You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Denis Magda <dm...@apache.org> on 2017/09/26 22:16:49 UTC
Re: Should we take care of Java 9 in Ignite 2.0 scope?
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 <dm...@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....@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 <hu...@gmail.com>:
>>
>>>
>>>
>>> JB IDEA2017.1 released, support jdk 9.
>>>
>>>
>>>
>>>
>>> On Fri, Mar 24, 2017 at 12:14 AM +0800, "Anton Vinogradov" <
>>> avinogradov@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 >
>>>>> dmagda@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/
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
Re: Should we take care of Java 9 in Ignite 2.0 scope?
Posted by Dmitry Pavlov <dp...@gmail.com>.
I'll personally would also greatly appreciate if ignite-core is build using
(source and target) version of JDK 8.
All contributors will be able to write code shorter and more expressively
using code Java 8.
ср, 4 окт. 2017 г. в 11:55, Yury Babak <y....@gmail.com>:
> It`s true, now building of ML cause pain because currently we need excess
> build of ignite-core using JDK 8.
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>
Re: Should we take care of Java 9 in Ignite 2.0 scope?
Posted by Yury Babak <y....@gmail.com>.
It`s true, now building of ML cause pain because currently we need excess
build of ignite-core using JDK 8.
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Re: Should we take care of Java 9 in Ignite 2.0 scope?
Posted by Nikita Ivanov <ni...@gmail.com>.
Yes, have a minimum set at Java 8 (ML contributors would greatly appreciate
that...).
--
Nikita Ivanov
On Tue, Sep 26, 2017 at 6:16 PM, Denis Magda <dm...@gridgain.com> wrote:
> You meant Java 7 drop I guess. That's a good question. Hope this happens
> soon.
>
> Denis
>
> On Tuesday, September 26, 2017, Nikita Ivanov <ni...@gmail.com> wrote:
>
> > What about Java 8 to begin with?
> >
> > --
> > Nikita Ivanov
> >
> >
> > On Tue, Sep 26, 2017 at 3:16 PM, Denis Magda <dmagda@apache.org
> > <javascript:;>> wrote:
> >
> > > 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 <dmagda@apache.org
> > <javascript:;>> 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.wk@gmail.com <javascript:;>> 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 <hufeng1987@gmail.com
> > <javascript:;>>:
> > > >>
> > > >>>
> > > >>>
> > > >>> JB IDEA2017.1 released, support jdk 9.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Fri, Mar 24, 2017 at 12:14 AM +0800, "Anton Vinogradov" <
> > > >>> avinogradov@gridgain.com <javascript:;>> 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 >
> > > >>>>> dmagda@apache.org <javascript:;>>> 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/
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >
> > >
> > >
> >
>
Re: Should we take care of Java 9 in Ignite 2.0 scope?
Posted by Denis Magda <dm...@gridgain.com>.
You meant Java 7 drop I guess. That's a good question. Hope this happens
soon.
Denis
On Tuesday, September 26, 2017, Nikita Ivanov <ni...@gmail.com> wrote:
> What about Java 8 to begin with?
>
> --
> Nikita Ivanov
>
>
> On Tue, Sep 26, 2017 at 3:16 PM, Denis Magda <dmagda@apache.org
> <javascript:;>> wrote:
>
> > 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 <dmagda@apache.org
> <javascript:;>> 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.wk@gmail.com <javascript:;>> 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 <hufeng1987@gmail.com
> <javascript:;>>:
> > >>
> > >>>
> > >>>
> > >>> JB IDEA2017.1 released, support jdk 9.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Fri, Mar 24, 2017 at 12:14 AM +0800, "Anton Vinogradov" <
> > >>> avinogradov@gridgain.com <javascript:;>> 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 >
> > >>>>> dmagda@apache.org <javascript:;>>> 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/
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> >
> >
>
Re: Should we take care of Java 9 in Ignite 2.0 scope?
Posted by Nikita Ivanov <ni...@gmail.com>.
What about Java 8 to begin with?
--
Nikita Ivanov
On Tue, Sep 26, 2017 at 3:16 PM, Denis Magda <dm...@apache.org> wrote:
> 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 <dm...@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.wk@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 <hu...@gmail.com>:
> >>
> >>>
> >>>
> >>> JB IDEA2017.1 released, support jdk 9.
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Mar 24, 2017 at 12:14 AM +0800, "Anton Vinogradov" <
> >>> avinogradov@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 >
> >>>>> dmagda@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/
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
>
>