ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@gridgain.com>
Subject Re: Should we take care of Java 9 in Ignite 2.0 scope?
Date Wed, 27 Sep 2017 01:16:02 GMT
You meant Java 7 drop I guess. That's a good question. Hope this happens
soon.

Denis

On Tuesday, September 26, 2017, Nikita Ivanov <nivanov30@gmail.com> wrote:

> What about Java 8 to begin with?
>
> --
> Nikita Ivanov
>
>
> On Tue, Sep 26, 2017 at 3:16 PM, Denis Magda <dmagda@apache.org
> <javascript:;>> wrote:
>
> > Eventually now it’s time to put all the doubts aside on when Ignite
> should
> > support JDK 9. The JDK is production ready and was released not long time
> > ago.
> >
> > Is there anyone interested to enable JDK 9 for Ignite?
> >
> > —
> > Denis
> >
> > > On Mar 24, 2017, at 10:22 AM, Denis Magda <dmagda@apache.org
> <javascript:;>> wrote:
> > >
> > > Evgenii,
> > >
> > > Thanks for the investigation. Could you update the ticket with all of
> > your findings and suggestions?
> > >
> > > If you feel you can’t fix it by 2.0 then let’s do it in the next minor
> > release like 2.x. I don’t think that we introduce any breaking
> > compatibilities when JDK 9 support is added later. Do you think so as
> well?
> > >
> > > —
> > > Denis
> > >
> > >> On Mar 24, 2017, at 9:24 AM, Evgenii Zhuravlev <
> > e.zhuravlev.wk@gmail.com <javascript:;>> wrote:
> > >>
> > >> Igniters,
> > >>
> > >> I found that maven-war-plugin, that used in ignite-websphere-test
> > doesn't
> > >> work with java 9. Here is issue:
> > >> https://issues.apache.org/jira/browse/MWAR-397.They have workaround
> > with
> > >> setting MAVEN_OPTS, but this workaround doesn't fit us.
> > >>
> > >> 2017-03-24 0:51 GMT+03:00 zixu mo <hufeng1987@gmail.com
> <javascript:;>>:
> > >>
> > >>>
> > >>>
> > >>> JB IDEA2017.1 released, support jdk 9.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Fri, Mar 24, 2017 at 12:14 AM +0800, "Anton Vinogradov" <
> > >>> avinogradov@gridgain.com <javascript:;>> wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> Denis,
> > >>>
> > >>> I'm not sure, but javac usage seems to be not our but IDE "problem".
> > >>> No one call javac directly, AFAIK.
> > >>>
> > >>> So, any --add-exports can be added to wrapping maven, .bat/.sh or IDE
> > >>> settings.
> > >>> I'm pretty sure JB's IDEA will handle this right after Java9 release
> :)
> > >>>
> > >>> On Wed, Mar 22, 2017 at 12:19 PM, Anton Vinogradov  wrote:
> > >>>
> > >>>> Denis,
> > >>>>
> > >>>> I'm not sure, but javac usage seems to be not our but IDE "problem".
> > >>>> No one call javac directly, AFAIK.
> > >>>>
> > >>>> So, any --add-exports can be added to wrapping maven, .bat/.sh
or
> IDE
> > >>>> settings.
> > >>>> I'm pretty sure JB's IDEA will handle this right after Java9 release
> > :)
> > >>>>
> > >>>> On Wed, Mar 22, 2017 at 1:43 AM, Denis Magda  wrote:
> > >>>>
> > >>>>> For using internal classes that not exported by default, we
will
> > need to
> > >>>>> add new args(--add-exports) when compiling (javac) *and* when
> running
> > >>>>> (java
> > >>>>> ).
> > >>>>> Is it ok?
> > >>>>>
> > >>>>>
> > >>>>> Anton, are you fine with this approach?
> > >>>>>
> > >>>>> —
> > >>>>> Denis
> > >>>>>
> > >>>>> On Mar 21, 2017, at 11:05 AM, Evgenii Zhuravlev
> > >>>>> wrote:
> > >>>>>
> > >>>>> Denis,
> > >>>>>
> > >>>>> I've found that some internal classes like sun.misc.SharedSecrets,
> > >>>>> sun.misc.URLClassPath, sun.misc.PerfCounter, sun.misc.Cleaner
> changed
> > >>>>> their
> > >>>>> packages. I can create wrapper for this classes with 2 modules,
> that
> > can
> > >>>>> be
> > >>>>> enabled by profiles for java9 and java7-8.
> > >>>>> For using internal classes that not exported by default, we
will
> > need to
> > >>>>> add new args(--add-exports) when compiling (javac) *and* when
> running
> > >>>>> (java
> > >>>>> ).
> > >>>>> Is it ok?
> > >>>>>
> > >>>>>
> > >>>>> Also, there are a two different Unsafe classes in java 9 -
> > >>>>> sun.misc.Unsafe
> > >>>>> & jdk.internal.misc.Unsafe, but both of them doesn't have
> > monitorEnter &
> > >>>>> monitorExit methods, that we use in
> > >>>>> org.apache.ignite.internal.util.GridUnsafe. What should I do
with
> > this
> > >>>>> case?
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> 2017-03-21 11:21 GMT+03:00 Евгений Журавлев
:
> > >>>>>
> > >>>>> Denis,
> > >>>>>
> > >>>>> I found some recommendations on openjdk wiki:
> > >>>>> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+
> > >>> Analysis+Tool
> > >>>>>
> > >>>>> 2017-03-20 20:44 GMT+03:00 Denis Magda :
> > >>>>>
> > >>>>> Referring to your report only the following API was removed
> > completely.
> > >>>>> The rest is still deprecated and stowed in special JDK 9 modules.
> > >>>>>
> > >>>>>
> > >>>>> "org.apache.ignite.internal.processors.hadoop.HadoopClassLoader"
> ->
> > >>>>> "sun.misc.PerfCounter (JDK internal API (JDK removed internal
> API))”;
> > >>>>>
> > >>>>>
> > >>>>> "org.apache.ignite.internal.processors.platform.memory.Pla
> > >>>>> tformMemoryPool"
> > >>>>> -> "sun.misc.Cleaner (JDK internal API (JDK removed internal
> API))”;
> > >>>>>
> > >>>>> "org.apache.ignite.internal.util.nio.GridNioServer$Abstrac
> > >>>>> tNioClientWorker"
> > >>>>> -> "sun.misc.Cleaner (JDK internal API (JDK removed internal
> API))";
> > >>>>>
> > >>>>>
> > >>>>> "org.apache.ignite.internal.processors.rest.protocols.GridRe
> > >>>>> stProtocolAdapter"
> > >>>>> -> "sun.misc.BASE64Encoder (JDK internal API (JDK removed
internal
> > >>> API))”;
> > >>>>>
> > >>>>> "org.apache.ignite.internal.util.IgniteUtils"      ->
> > >>>>> "sun.misc.JavaNetAccess (JDK internal API (JDK removed internal
> > API))”;
> > >>>>>
> > >>>>>
> > >>>>> "org.apache.ignite.internal.util.IgniteUtils"      ->
> > >>>>> "sun.misc.SharedSecrets (JDK internal API (JDK removed internal
> > API))”;
> > >>>>>
> > >>>>>
> > >>>>> "org.apache.ignite.internal.util.IgniteUtils"      ->
> > >>>>> "sun.misc.URLClassPath (JDK internal API (JDK removed internal
> > API))”;
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> *Evgeniy*, does Oracle officially suggest replacements for
deleted
> > APIs?
> > >>>>> Probably it’s a matter of day to do a switch.
> > >>>>>
> > >>>>>
> > >>>>> —
> > >>>>> Denis
> > >>>>>
> > >>>>> On Mar 20, 2017, at 9:57 AM, Евгений Журавлев
> > >>>>>
> > >>>>> wrote:
> > >>>>>
> > >>>>>
> > >>>>> Igniters,
> > >>>>>
> > >>>>> There are a few JDK internal APIs removed in JDK 9, that we
use in
> > >>>>>
> > >>>>> ignite. We need to decide what to do with these dependencies.
Here
> > is a
> > >>>>> list of dependencies after using jdeps
> > >>>>>
> > >>>>>
> > >>>>> 2017-01-26 12:07 GMT+03:00 Anton Vinogradov >
> > >>>>>>> :
> > >>>>>
> > >>>>> Denis,
> > >>>>>
> > >>>>> I've created issue >
> > >>>>> https://issues.apache.org/jira/browse/IGNITE-4615>> related
> > >>>>>
> > >>>>> to discussion.
> > >>>>> We have a lot of legacy code inside pom.xml files. One of legacy
> > issues
> > >>>>>
> > >>>>> is
> > >>>>>
> > >>>>> a tools.jar usage.
> > >>>>> So, it will be nice to fix this as well.
> > >>>>>
> > >>>>> On Thu, Jan 26, 2017 at 2:54 AM, Denis Magda >
> > >>>>>>> wrote:
> > >>>>>
> > >>>>>
> > >>>>> Well, the build fails almost immediately on the latest JDK
9.
> > >>>>>
> > >>>>> This is the reason (https://issues.jenkins-ci.org
> > >>>>>
> > >>>>> /browse/JENKINS-25993 >
> > >>>>> ).
> > >>>>>
> > >>>>>
> > >>>>> [ERROR] Failed to execute goal on project ignite-tools: Could
not
> > >>>>>
> > >>>>> resolve
> > >>>>>
> > >>>>> dependencies for project org.apache.ignite:ignite-tools
> > >>>>>
> > >>>>> :jar:2.0.0-SNAPSHOT:
> > >>>>>
> > >>>>> Could not find artifact com.sun:tools:jar:9-ea at specified
path
> > >>>>> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/..
> > >>>>>
> > >>>>> /lib/tools.jar
> > >>>>>
> > >>>>> -> [Help 1]
> > >>>>>
> > >>>>>
> > >>>>> If to tweak pom files cleaning out references to tools.jar
then
> other
> > >>>>> exceptions arise.
> > >>>>>
> > >>>>> *Anton V*, could try to build the master on your side applying
all
> > the
> > >>>>> required changes to pom files? I don’t think I’ll do everything
> > >>>>>
> > >>>>> correctly.
> > >>>>>
> > >>>>> If the build goes through at least with minor modifications
then
> this
> > >>>>>
> > >>>>> would
> > >>>>>
> > >>>>> be a good sign.
> > >>>>>
> > >>>>> —
> > >>>>> Denis
> > >>>>>
> > >>>>>
> > >>>>> On Jan 25, 2017, at 3:22 PM, Denis Magda >
> > >>>>> dmagda@apache.org <javascript:;>>> wrote:
> > >>>>>
> > >>>>>
> > >>>>> Vovan,
> > >>>>>
> > >>>>> As far as I understand, under the module they mean new
> > >>>>>
> > >>>>> component/feature
> > >>>>>
> > >>>>> of Java 9 [1]. If you don’t use Java modules then there shouldn’t
> be
> > >>>>>
> > >>>>> any
> > >>>>>
> > >>>>> issues at all.
> > >>>>>
> > >>>>> In any case, let me try to build the project with JDK 9 that
has
> > >>>>>
> > >>>>> passed
> > >>>>>
> > >>>>> feature complete phase.
> > >>>>>
> > >>>>> [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/#defining
> > >>>>>
> > >>>>> -modules > g-modules> <
> > >>>>>
> > >>>>> http://openjdk.java.net/projects/jigsaw/spec/sotms/#
> defining-modules
> > >>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> —
> > >>>>> Denis
> > >>>>>
> > >>>>> On Jan 25, 2017, at 5:47 AM, Vladimir Ozerov >
> > >>>>>>> wrote:
> > >>>>>
> > >>>>>
> > >>>>> Igniters,
> > >>>>>
> > >>>>> Please see this article [1] from Kotlin guys. They had to re-pack
> > >>>>>
> > >>>>> public
> > >>>>>
> > >>>>> API because Java 9 doesn't allow several modules to share the
same
> > >>>>>
> > >>>>> public
> > >>>>>
> > >>>>> package. Looks like this limitation could impact us at some
point,
> so
> > >>>>>
> > >>>>> that
> > >>>>>
> > >>>>> we will not be able to support Java 9 without breaking API
changes.
> > >>>>>
> > >>>>> May be it makes sense to perform some initial investigation
of
> Java 9
> > >>>>> impact before AI 2.0 release, so that we can minimize (or at
least
> > >>>>> estimate) potential future impact?
> > >>>>>
> > >>>>> Vladimir.
> > >>>>>
> > >>>>> [1]
> > >>>>> https://blog.jetbrains.com/kotlin/2017/01/kotlin-1-1- <
> > >>>>>
> > >>>>> https://blog.jetbrains.com/kotlin/2017/01/kotlin-1-1->
> > >>>>>
> > >>>>> whats-coming-in-the-standard-library/
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> >
> >
>

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