Should we take care of Java 9 in Ignite 2.0 scope?

[Vladimir Ozerov]

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-whats-coming-in-the-standard-library/

[yzhdanov]

Agree. We need to start tests with 9 as soon as possible.

--Yakov

2017-01-25 16:47 GMT+03:00 Vladimir Ozerov <[hidden email]>:

> 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-
> whats-coming-in-the-standard-library/
>

[dsetrakyan]

+1

On Wed, Jan 25, 2017 at 6:45 AM, Yakov Zhdanov <[hidden email]> wrote:

> Agree. We need to start tests with 9 as soon as possible.
>
> --Yakov
>
> 2017-01-25 16:47 GMT+03:00 Vladimir Ozerov <[hidden email]>:
>
> > 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-
> > whats-coming-in-the-standard-library/
> >
>

[nivanov]

+1

--
Nikita Ivanov


On Wed, Jan 25, 2017 at 12:31 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> +1
>
> On Wed, Jan 25, 2017 at 6:45 AM, Yakov Zhdanov <[hidden email]>
> wrote:
>
> > Agree. We need to start tests with 9 as soon as possible.
> >
> > --Yakov
> >
> > 2017-01-25 16:47 GMT+03:00 Vladimir Ozerov <[hidden email]>:
> >
> > > 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-
> > > whats-coming-in-the-standard-library/
> > >
> >
>

[dmagda]

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/#defining-modules>

—
Denis

> On Jan 25, 2017, at 5:47 AM, Vladimir Ozerov <[hidden email]> 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-whats-coming-in-the-standard-library/

[dmagda]

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 <[hidden email]> 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/#defining-modules>
>
> —
> Denis
>
>> On Jan 25, 2017, at 5:47 AM, Vladimir Ozerov <[hidden email]> 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-whats-coming-in-the-standard-library/
>

[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 <[hidden email]> 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 <[hidden email]> 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/#defining-modules>
>
> —
> Denis
>
> On Jan 25, 2017, at 5:47 AM, Vladimir Ozerov <[hidden email]> 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-
> whats-coming-in-the-standard-library/
>
>
>
>

[ezhuravl]

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]> 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/#defining-modules>
>
> —
> Denis
>
> On Jan 25, 2017, at 5:47 AM, Vladimir Ozerov <[hidden email]> 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-
> whats-coming-in-the-standard-library/
>
>
>
>

[dmagda]

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, Евгений Журавлев <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>>:
> 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 <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> 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/#defining-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 <[hidden email] <mailto:[hidden email]>> 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/
> >
> >
> >
> >
>

[ezhuravl]

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 Евгений Журавлев <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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, Евгений Журавлев <[hidden email]>
>> 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 <[hidden email]
>> <mailto:[hidden email]>>:
>> > 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 <[hidden email]
>> <mailto:[hidden email]>> 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 <[hidden email] <mailto:
>> [hidden email]>> 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 <[hidden email]
>> <mailto:[hidden email]>> 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/
>> > >
>> > >
>> > >
>> > >
>> >
>>
>>
>

[Vladimir Ozerov]

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 <[hidden email]
> 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 Евгений Журавлев <[hidden email]>:
>
> > 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 <[hidden email]>:
> >
> >> 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, Евгений Журавлев <
> [hidden email]>
> >> 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 <[hidden email]
> >> <mailto:[hidden email]>>:
> >> > 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 <[hidden email]
> >> <mailto:[hidden email]>> 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 <[hidden email]
> <mailto:
> >> [hidden email]>> 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 <[hidden email]
> >> <mailto:[hidden email]>> 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/
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >>
> >
>

[dmagda]

> 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 <[hidden email]> 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 Евгений Журавлев <[hidden email] <mailto:[hidden email]>>:
>
>> Denis,
>>
>> I found some recommendations on openjdk wiki:
>> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool <https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool>
>>
>> 2017-03-20 20:44 GMT+03:00 Denis Magda <[hidden email] <mailto:[hidden email]>>:
>>
>>> 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, Евгений Журавлев <[hidden email]>
>>> 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 <[hidden email]
>>> <mailto:[hidden email] <mailto:[hidden email]>>>:
>>>> Denis,
>>>>
>>>> I've created issue <https://issues.apache.org/jira/browse/IGNITE-4615 <https://issues.apache.org/jira/browse/IGNITE-4615> <
>>> 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 <[hidden email] <mailto:[hidden email]>
>>> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>>>>
>>>>> Well, the build fails almost immediately on the latest JDK 9.
>>>>>
>>>>> This is the reason (https://issues.jenkins-ci.org <https://issues.jenkins-ci.org/>
>>> /browse/JENKINS-25993 <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 <[hidden email] <mailto:[hidden email]> <mailto:
>>> [hidden email] <mailto:[hidden email]>>> 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 <http://openjdk.java.net/projects/jigsaw/spec/sotms/#defining>
>>> -modules <http://openjdk.java.net/projects/jigsaw/spec/sotms/#definin <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>
>>> <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 <[hidden email] <mailto:[hidden email]>
>>> <mailto:[hidden email] <mailto:[hidden email]>>> 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-> <
>>> 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/

[Anton Vinogradov]

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 <[hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
>> 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 Евгений Журавлев <[hidden email]>:
>>
>> 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 <[hidden email]>:
>>
>> 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, Евгений Журавлев <[hidden email]>
>>
>> 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 <[hidden email]
>>
>> <mailto:[hidden email] <[hidden email]>>>:
>>
>> 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 <[hidden email]
>>
>> <mailto:[hidden email] <[hidden email]>>> 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 <[hidden email] <mailto:
>>
>> [hidden email]>> 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 <[hidden email]
>>
>> <mailto:[hidden email] <[hidden email]>>> 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/
>>
>>
>>
>

[zixu mo]

JB IDEA2017.1 released, support jdk 9.




On Fri, Mar 24, 2017 at 12:14 AM +0800, "Anton Vinogradov" <[hidden email]> 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 >
>> [hidden email]>> 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/
>>
>>
>>
>

[ezhuravl]

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 <[hidden email]>:

>
>
> JB IDEA2017.1 released, support jdk 9.
>
>
>
>
> On Fri, Mar 24, 2017 at 12:14 AM +0800, "Anton Vinogradov" <
> [hidden email]> 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 >
> >> [hidden email]>> 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/
> >>
> >>
> >>
> >
>
>
>
>
>
>

[dmagda]

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 <[hidden email]> 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 <[hidden email]>:
>
>>
>>
>> JB IDEA2017.1 released, support jdk 9.
>>
>>
>>
>>
>> On Fri, Mar 24, 2017 at 12:14 AM +0800, "Anton Vinogradov" <
>> [hidden email]> 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 >
>>>> [hidden email]>> 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/
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>>

[dmagda]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>
>>>
>>>
>>> JB IDEA2017.1 released, support jdk 9.
>>>
>>>
>>>
>>>
>>> On Fri, Mar 24, 2017 at 12:14 AM +0800, "Anton Vinogradov" <
>>> [hidden email]> 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 >
>>>>> [hidden email]>> 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/
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>

[nivanov]

What about Java 8 to begin with?

--
Nikita Ivanov


On Tue, Sep 26, 2017 at 3:16 PM, Denis Magda <[hidden email]> 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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]>:
> >>
> >>>
> >>>
> >>> JB IDEA2017.1 released, support jdk 9.
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Mar 24, 2017 at 12:14 AM +0800, "Anton Vinogradov" <
> >>> [hidden email]> 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 >
> >>>>> [hidden email]>> 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/
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
>
>

[Denis Magda]

You meant Java 7 drop I guess. That's a good question. Hope this happens
soon.

Denis

On Tuesday, September 26, 2017, Nikita Ivanov <[hidden email]> wrote:

> What about Java 8 to begin with?
>
> --
> Nikita Ivanov
>
>
> On Tue, Sep 26, 2017 at 3:16 PM, Denis Magda <[hidden email]
> <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 <[hidden email]
> <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 <
> > [hidden email] <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 <[hidden email]
> <javascript:;>>:
> > >>
> > >>>
> > >>>
> > >>> JB IDEA2017.1 released, support jdk 9.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Fri, Mar 24, 2017 at 12:14 AM +0800, "Anton Vinogradov" <
> > >>> [hidden email] <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 >
> > >>>>> [hidden email] <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/
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> >
> >
>

[nivanov]

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 <[hidden email]> 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 <[hidden email]> wrote:
>
> > What about Java 8 to begin with?
> >
> > --
> > Nikita Ivanov
> >
> >
> > On Tue, Sep 26, 2017 at 3:16 PM, Denis Magda <[hidden email]
> > <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 <[hidden email]
> > <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 <
> > > [hidden email] <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 <[hidden email]
> > <javascript:;>>:
> > > >>
> > > >>>
> > > >>>
> > > >>> JB IDEA2017.1 released, support jdk 9.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> On Fri, Mar 24, 2017 at 12:14 AM +0800, "Anton Vinogradov" <
> > > >>> [hidden email] <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 >
> > > >>>>> [hidden email] <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/
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >
> > >
> > >
> >
>