So just one bit to consider... Are there features that you need to use in these
newer versions of java? Or are we just updating to stay current? The reason I
ask is that there are still lots of people in an enterprise space that are
beholden to having to support legacy JAVAEE supported applications on
Websphere, Weblogic, Redhat, etc... and the organizations that use those
platforms are slow to move... Most of them are still on Java8
So as a platform I think a strong consideration needs to be towards having the
broadest possible support profile until it becomes an impediment to doing
things that the platform needs. So far I haven't seen huge things in the newer
versions of java that are must haves ( a few exceptions are things that would
be really nice to take advantage of ).
I think that apache commons has taken the right approach by staying on java 8
giving the largest possible user base.
Even standardizing on java 11 would have to make us reconsider Ignite as the
platform we are using, we are not so invested in it as of now, even though we
have big plans to leverage it. Just because we aren't sure when we are going to
be able to upgrade from java8. It has support through 2022, so I imagine that
is when we will be discussing that.
Regards
~Adam
Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline
Technologies
Office: 603-501-6446 | Mobile: 603-570-8418
www.bottomline.com
On 11/24/20, 7:38 AM, "Alexey Zinoviev" <zaleslaw....@gmail.com> wrote:
Java 15 is better, VarHandles, ForeignMemory access and so on.
In both cases, I support the Java version 11 and higher for the development!
вт, 24 нояб. 2020 г. в 15:21, Andrey Mashenkov <andrey.mashen...@gmail.com>:
> Let's add maven plugins for sanity checks at the early stage.
> I've created a ticket for this [1].
>
> Also, I've found initial pom.xml has a target version Java 8.
> Do we intend to move to Java 11 (or may be next LTS) and drop Java 8 in
> Ignite 3.0?
>
> [1]
https://urldefense.com/v3/__https://issues.apache.org/jira/browse/IGNITE-13751__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKAO2Ejs8$
>
> On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Folks,
> >
> > I went ahead and created the repository [1]. I also configured a
TeamCity
> > project [2] that runs all available JUnit tests on every PR creation or
> > update. It also sends the status update to GitHub so that it's reflected
> in
> > the PR itself so that we can do merges directly from GitHub. Basic steps
> to
> > make a change are described on the Wiki page [3].
> >
> > Let me know if you have any questions.
> >
> > [1]
https://urldefense.com/v3/__https://github.com/apache/ignite-3__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKIq24lxF$
> > [2]
https://urldefense.com/v3/__https://ci.ignite.apache.org/project/ignite3__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKFGL_oJx$
> > [3]
> >
> >
>
https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0*ApacheIgnite3.0-DevelopmentProcess__;Kysj!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKNhWzQ0s$
> >
> > -Val
> >
> > On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Thanks, guys. It looks like we are much closer to the consensus now. I
> > > totally on board with the plan, but I would also like to address the
> > > short-term needs. As I've already mentioned earlier, there are several
> > > active IEPs, but we still don't have even a preliminary technical
> process
> > > for working on these IEPs. I believe this might be frustrating for the
> > > folks who would like to commit code.
> > >
> > > The scope we agreed on is quite big, and it will surely take
> significant
> > > time to implement all the changes and stabilize them. Therefore, it's
> > clear
> > > to me that we will have to maintain 2.x and 3.x in parallel for quite
> > some
> > > time - this needs to be addressed somehow. I'm convinced that having a
> > > separate repo is the ONLY way to do that, and so far, I haven't heard
> any
> > > clear alternatives or reasons why we shouldn't do this.
> > >
> > > That said, I'm inclined to proceed with this in the next few days - I
> > will
> > > create a repo and describe the process (which we, of course, can
> discuss
> > > and modify going forward). Let's, at the very least, try and see where
> it
> > > leads us.
> > >
> > > If someone has any concrete alternative options on how to we can
> maintain
> > > two major versions in parallel, let's have another voice discussion
> this
> > > Friday. If we do the meeting, we should set it up with a clear goal to
> > make
> > > a decision. Please let me know if there is interest in this.
> > >
> > > -Val
> > >
> > > On Mon, Nov 16, 2020 at 6:31 AM Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > >> Good,
> > >>
> > >> I think we have an intermediate agreement on the scope and
> significance
> > of
> > >> the changes we want to make. I suggest creating separate discussion
> > >> streams
> > >> and calls for each of the suggested topics so that:
> > >>
> > >> - It is clear for the community what is the motivation of the
> stream
> > >> (this includes both functional targets and technical debt issues
> > >> pointed
> > >> out by Sergey)
> > >> - Who is planning to take an active part in each of the streams
> (i.e.
> > >> the 'design committee', as Sergey suggested)
> > >> - What are the intermediate and final goals for each of the
streams
> > >> - What are the cross-stream interactions and how we integrate them
> > >> - How each of the streams will be integrated with the current
> > codebase
> > >> based on the above (here is where we will see whether drop-in or
> > >> incremental approaches make more sense)
> > >>
> > >
> >
>
>
> --
> Best regards,
> Andrey V. Mashenkov
>
