ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evgenii Zhuravlev <e.zhuravlev...@gmail.com>
Subject Re: Should we take care of Java 9 in Ignite 2.0 scope?
Date Tue, 21 Mar 2017 18:05:49 GMT
Denis,

I've found that some internal classes like sun.misc.SharedSecrets,
sun.misc.URLClassPath, sun.misc.PerfCounter, sun.misc.Cleaner changed their
packages. I can create wrapper for this classes with 2 modules, that can be
enabled by profiles for java9 and java7-8.
For using internal classes that not exported by default, we will need to
add new args(--add-exports) when compiling (javac) *and* when running (java
).
Is it ok?


Also, there are a two different Unsafe classes in java 9 -  sun.misc.Unsafe
& jdk.internal.misc.Unsafe, but both of them doesn't have monitorEnter &
monitorExit methods, that we use in
org.apache.ignite.internal.util.GridUnsafe. What should I do with this case?



2017-03-21 11:21 GMT+03:00 Евгений Журавлев <e.zhuravlev.wk@gmail.com>:

> Denis,
>
> I found some recommendations on openjdk wiki:
> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
>
> 2017-03-20 20:44 GMT+03:00 Denis Magda <dmagda@apache.org>:
>
>> Referring to your report only the following API was removed completely.
>> The rest is still deprecated and stowed in special JDK 9 modules.
>>
>>
>>    "org.apache.ignite.internal.processors.hadoop.HadoopClassLoader" ->
>> "sun.misc.PerfCounter (JDK internal API (JDK removed internal API))”;
>>
>>
>>    "org.apache.ignite.internal.processors.platform.memory.PlatformMemoryPool"
>> -> "sun.misc.Cleaner (JDK internal API (JDK removed internal API))”;
>>
>>    "org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker"
>> -> "sun.misc.Cleaner (JDK internal API (JDK removed internal API))";
>>
>>
>> "org.apache.ignite.internal.processors.rest.protocols.GridRestProtocolAdapter"
>> -> "sun.misc.BASE64Encoder (JDK internal API (JDK removed internal API))”;
>>
>> "org.apache.ignite.internal.util.IgniteUtils"      ->
>> "sun.misc.JavaNetAccess (JDK internal API (JDK removed internal API))”;
>>
>>
>>    "org.apache.ignite.internal.util.IgniteUtils"      ->
>> "sun.misc.SharedSecrets (JDK internal API (JDK removed internal API))”;
>>
>>
>>    "org.apache.ignite.internal.util.IgniteUtils"      ->
>> "sun.misc.URLClassPath (JDK internal API (JDK removed internal API))”;
>>
>>
>>
>> *Evgeniy*, does Oracle officially suggest replacements for deleted APIs?
>> Probably it’s a matter of day to do a switch.
>>
>>
>> —
>> Denis
>>
>> > On Mar 20, 2017, at 9:57 AM, Евгений Журавлев <e.zhuravlev.wk@gmail.com>
>> wrote:
>> >
>> > Igniters,
>> >
>> > There are a few JDK internal APIs removed in JDK 9, that we use in
>> ignite. We need to decide what to do with these dependencies. Here is a
>> list of dependencies after using jdeps
>> >
>> > 2017-01-26 12:07 GMT+03:00 Anton Vinogradov <avinogradov@gridgain.com
>> <mailto:avinogradov@gridgain.com>>:
>> > Denis,
>> >
>> > I've created issue <https://issues.apache.org/jira/browse/IGNITE-4615 <
>> https://issues.apache.org/jira/browse/IGNITE-4615>> related
>> > to discussion.
>> > We have a lot of legacy code inside pom.xml files. One of legacy issues
>> is
>> > a tools.jar usage.
>> > So, it will be nice to fix this as well.
>> >
>> > On Thu, Jan 26, 2017 at 2:54 AM, Denis Magda <dmagda@apache.org
>> <mailto:dmagda@apache.org>> wrote:
>> >
>> > > Well, the build fails almost immediately on the latest JDK 9.
>> > >
>> > > This is the reason (https://issues.jenkins-ci.org
>> /browse/JENKINS-25993 <https://issues.jenkins-ci.org/browse/JENKINS-25993
>> >).
>> > >
>> > > [ERROR] Failed to execute goal on project ignite-tools: Could not
>> resolve
>> > > dependencies for project org.apache.ignite:ignite-tools
>> :jar:2.0.0-SNAPSHOT:
>> > > Could not find artifact com.sun:tools:jar:9-ea at specified path
>> > > /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/..
>> /lib/tools.jar
>> > > -> [Help 1]
>> > >
>> > >
>> > > If to tweak pom files cleaning out references to tools.jar then other
>> > > exceptions arise.
>> > >
>> > > *Anton V*, could try to build the master on your side applying all the
>> > > required changes to pom files? I don’t think I’ll do everything
>> correctly.
>> > > If the build goes through at least with minor modifications then this
>> would
>> > > be a good sign.
>> > >
>> > > —
>> > > Denis
>> > >
>> > >
>> > > On Jan 25, 2017, at 3:22 PM, Denis Magda <dmagda@apache.org <mailto:
>> dmagda@apache.org>> wrote:
>> > >
>> > > Vovan,
>> > >
>> > > As far as I understand, under the module they mean new
>> component/feature
>> > > of Java 9 [1]. If you don’t use Java modules then there shouldn’t be
>> any
>> > > issues at all.
>> > >
>> > > In any case, let me try to build the project with JDK 9 that has
>> passed
>> > > feature complete phase.
>> > >
>> > > [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#defining
>> -modules <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 <vozerov@gridgain.com
>> <mailto:vozerov@gridgain.com>> wrote:
>> > >
>> > > Igniters,
>> > >
>> > > Please see this article [1] from Kotlin guys. They had to re-pack
>> public
>> > > API because Java 9 doesn't allow several modules to share the same
>> public
>> > > package. Looks like this limitation could impact us at some point, so
>> that
>> > > we will not be able to support Java 9 without breaking API changes.
>> > >
>> > > May be it makes sense to perform some initial investigation of Java 9
>> > > impact before AI 2.0 release, so that we can minimize (or at least
>> > > estimate) potential future impact?
>> > >
>> > > Vladimir.
>> > >
>> > > [1]
>> > > https://blog.jetbrains.com/kotlin/2017/01/kotlin-1-1- <
>> https://blog.jetbrains.com/kotlin/2017/01/kotlin-1-1->
>> > > whats-coming-in-the-standard-library/
>> > >
>> > >
>> > >
>> > >
>> >
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message