You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Jonathan Ellis <jb...@gmail.com> on 2015/05/07 18:09:05 UTC
Requiring Java 8 for C* 3.0
We discussed requiring Java 8 previously and decided to remain Java
7-compatible, but at the time we were planning to release 3.0 before Java 7
EOL. Now that 8099 and increased emphasis on QA have delayed us past Java
7 EOL, I think it's worth reopening this discussion.
If we require 8, then we can use lambdas, LongAdder, StampedLock, Streaming
collections, default methods, etc. Not just in 3.0 but over 3.x for the
next year.
If we don't, then people can choose whether to deploy on 7 or 8 -- but the
vast majority will deploy on 8 simply because 7 is no longer supported
without a premium contract with Oracle. 8 also has a more advanced G1GC
implementation (see CASSANDRA-7486).
I think that gaining access to the new features in 8 as we develop 3.x is
worth losing the ability to run on a platform that will have been EOL for a
couple months by the time we release.
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced
Re: Requiring Java 8 for C* 3.0
Posted by Pierre-Yves Ritschard <py...@spootnik.org>.
What would be the recommended JDK, is Hotspot still the way to go or do
JDK8 users already consider OpenJDK production-grade now ?
On 05/07/2015 07:00 PM, Jonathan Ellis wrote:
> Yes, it is.
>
Re: Requiring Java 8 for C* 3.0
Posted by Jonathan Ellis <jb...@gmail.com>.
Yes, it is.
On Thu, May 7, 2015 at 9:43 AM, Nick Bailey <ni...@datastax.com> wrote:
> Is running 2.1 with java 8 a supported or recommended way to run at this
> point? If not then we'll be requiring users to upgrade both java and C* at
> the same time when making the jump to 3.0.
>
> On Thu, May 7, 2015 at 11:25 AM, Aleksey Yeschenko <al...@apache.org>
> wrote:
>
> > The switch will necessarily hurt 3.0 adoption, but I think we’ll live. To
> > me, the benefits (mostly access to lambdas and default methods, tbh)
> > slightly outweigh the downsides.
> >
> > +0.1
> >
> > --
> > AY
> >
> > On May 7, 2015 at 19:22:53, Gary Dusbabek (gdusbabek@gmail.com) wrote:
> >
> > +1
> >
> > On Thu, May 7, 2015 at 11:09 AM, Jonathan Ellis <jb...@gmail.com>
> wrote:
> >
> > > We discussed requiring Java 8 previously and decided to remain Java
> > > 7-compatible, but at the time we were planning to release 3.0 before
> > Java 7
> > > EOL. Now that 8099 and increased emphasis on QA have delayed us past
> Java
> > > 7 EOL, I think it's worth reopening this discussion.
> > >
> > > If we require 8, then we can use lambdas, LongAdder, StampedLock,
> > Streaming
> > > collections, default methods, etc. Not just in 3.0 but over 3.x for the
> > > next year.
> > >
> > > If we don't, then people can choose whether to deploy on 7 or 8 -- but
> > the
> > > vast majority will deploy on 8 simply because 7 is no longer supported
> > > without a premium contract with Oracle. 8 also has a more advanced G1GC
> > > implementation (see CASSANDRA-7486).
> > >
> > > I think that gaining access to the new features in 8 as we develop 3.x
> is
> > > worth losing the ability to run on a platform that will have been EOL
> > for a
> > > couple months by the time we release.
> > >
> > > --
> > > Jonathan Ellis
> > > Project Chair, Apache Cassandra
> > > co-founder, http://www.datastax.com
> > > @spyced
> > >
> >
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced
Re: Requiring Java 8 for C* 3.0
Posted by Jeremy Hanna <je...@gmail.com>.
There’s no reason why people can’t run java 8 with 2.1. IIRC the only issue we’d had with it was Dave’s https://issues.apache.org/jira/browse/CASSANDRA-7028. That’s probably the best thing for people to do though - run java 8 with 2.1 so the jump to 3.0 isn’t as significant. Good point.
> On May 7, 2015, at 11:43 AM, Nick Bailey <ni...@datastax.com> wrote:
>
> Is running 2.1 with java 8 a supported or recommended way to run at this
> point? If not then we'll be requiring users to upgrade both java and C* at
> the same time when making the jump to 3.0.
>
> On Thu, May 7, 2015 at 11:25 AM, Aleksey Yeschenko <al...@apache.org>
> wrote:
>
>> The switch will necessarily hurt 3.0 adoption, but I think we’ll live. To
>> me, the benefits (mostly access to lambdas and default methods, tbh)
>> slightly outweigh the downsides.
>>
>> +0.1
>>
>> --
>> AY
>>
>> On May 7, 2015 at 19:22:53, Gary Dusbabek (gdusbabek@gmail.com) wrote:
>>
>> +1
>>
>> On Thu, May 7, 2015 at 11:09 AM, Jonathan Ellis <jb...@gmail.com> wrote:
>>
>>> We discussed requiring Java 8 previously and decided to remain Java
>>> 7-compatible, but at the time we were planning to release 3.0 before
>> Java 7
>>> EOL. Now that 8099 and increased emphasis on QA have delayed us past Java
>>> 7 EOL, I think it's worth reopening this discussion.
>>>
>>> If we require 8, then we can use lambdas, LongAdder, StampedLock,
>> Streaming
>>> collections, default methods, etc. Not just in 3.0 but over 3.x for the
>>> next year.
>>>
>>> If we don't, then people can choose whether to deploy on 7 or 8 -- but
>> the
>>> vast majority will deploy on 8 simply because 7 is no longer supported
>>> without a premium contract with Oracle. 8 also has a more advanced G1GC
>>> implementation (see CASSANDRA-7486).
>>>
>>> I think that gaining access to the new features in 8 as we develop 3.x is
>>> worth losing the ability to run on a platform that will have been EOL
>> for a
>>> couple months by the time we release.
>>>
>>> --
>>> Jonathan Ellis
>>> Project Chair, Apache Cassandra
>>> co-founder, http://www.datastax.com
>>> @spyced
>>>
>>
Re: Requiring Java 8 for C* 3.0
Posted by Nick Bailey <ni...@datastax.com>.
Is running 2.1 with java 8 a supported or recommended way to run at this
point? If not then we'll be requiring users to upgrade both java and C* at
the same time when making the jump to 3.0.
On Thu, May 7, 2015 at 11:25 AM, Aleksey Yeschenko <al...@apache.org>
wrote:
> The switch will necessarily hurt 3.0 adoption, but I think we’ll live. To
> me, the benefits (mostly access to lambdas and default methods, tbh)
> slightly outweigh the downsides.
>
> +0.1
>
> --
> AY
>
> On May 7, 2015 at 19:22:53, Gary Dusbabek (gdusbabek@gmail.com) wrote:
>
> +1
>
> On Thu, May 7, 2015 at 11:09 AM, Jonathan Ellis <jb...@gmail.com> wrote:
>
> > We discussed requiring Java 8 previously and decided to remain Java
> > 7-compatible, but at the time we were planning to release 3.0 before
> Java 7
> > EOL. Now that 8099 and increased emphasis on QA have delayed us past Java
> > 7 EOL, I think it's worth reopening this discussion.
> >
> > If we require 8, then we can use lambdas, LongAdder, StampedLock,
> Streaming
> > collections, default methods, etc. Not just in 3.0 but over 3.x for the
> > next year.
> >
> > If we don't, then people can choose whether to deploy on 7 or 8 -- but
> the
> > vast majority will deploy on 8 simply because 7 is no longer supported
> > without a premium contract with Oracle. 8 also has a more advanced G1GC
> > implementation (see CASSANDRA-7486).
> >
> > I think that gaining access to the new features in 8 as we develop 3.x is
> > worth losing the ability to run on a platform that will have been EOL
> for a
> > couple months by the time we release.
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>
Re: Requiring Java 8 for C* 3.0
Posted by Aleksey Yeschenko <al...@apache.org>.
The switch will necessarily hurt 3.0 adoption, but I think we’ll live. To me, the benefits (mostly access to lambdas and default methods, tbh) slightly outweigh the downsides.
+0.1
--
AY
On May 7, 2015 at 19:22:53, Gary Dusbabek (gdusbabek@gmail.com) wrote:
+1
On Thu, May 7, 2015 at 11:09 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> We discussed requiring Java 8 previously and decided to remain Java
> 7-compatible, but at the time we were planning to release 3.0 before Java 7
> EOL. Now that 8099 and increased emphasis on QA have delayed us past Java
> 7 EOL, I think it's worth reopening this discussion.
>
> If we require 8, then we can use lambdas, LongAdder, StampedLock, Streaming
> collections, default methods, etc. Not just in 3.0 but over 3.x for the
> next year.
>
> If we don't, then people can choose whether to deploy on 7 or 8 -- but the
> vast majority will deploy on 8 simply because 7 is no longer supported
> without a premium contract with Oracle. 8 also has a more advanced G1GC
> implementation (see CASSANDRA-7486).
>
> I think that gaining access to the new features in 8 as we develop 3.x is
> worth losing the ability to run on a platform that will have been EOL for a
> couple months by the time we release.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>
Re: Requiring Java 8 for C* 3.0
Posted by Gary Dusbabek <gd...@gmail.com>.
+1
On Thu, May 7, 2015 at 11:09 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> We discussed requiring Java 8 previously and decided to remain Java
> 7-compatible, but at the time we were planning to release 3.0 before Java 7
> EOL. Now that 8099 and increased emphasis on QA have delayed us past Java
> 7 EOL, I think it's worth reopening this discussion.
>
> If we require 8, then we can use lambdas, LongAdder, StampedLock, Streaming
> collections, default methods, etc. Not just in 3.0 but over 3.x for the
> next year.
>
> If we don't, then people can choose whether to deploy on 7 or 8 -- but the
> vast majority will deploy on 8 simply because 7 is no longer supported
> without a premium contract with Oracle. 8 also has a more advanced G1GC
> implementation (see CASSANDRA-7486).
>
> I think that gaining access to the new features in 8 as we develop 3.x is
> worth losing the ability to run on a platform that will have been EOL for a
> couple months by the time we release.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>
Re: Requiring Java 8 for C* 3.0
Posted by Ryan McGuire <ry...@datastax.com>.
+1, from a testing perspective we run dtest and unit tests on hotspot 8 and
openjdk 8 and have seen no problems.
On Thu, May 7, 2015 at 12:09 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> We discussed requiring Java 8 previously and decided to remain Java
> 7-compatible, but at the time we were planning to release 3.0 before Java 7
> EOL. Now that 8099 and increased emphasis on QA have delayed us past Java
> 7 EOL, I think it's worth reopening this discussion.
>
> If we require 8, then we can use lambdas, LongAdder, StampedLock, Streaming
> collections, default methods, etc. Not just in 3.0 but over 3.x for the
> next year.
>
> If we don't, then people can choose whether to deploy on 7 or 8 -- but the
> vast majority will deploy on 8 simply because 7 is no longer supported
> without a premium contract with Oracle. 8 also has a more advanced G1GC
> implementation (see CASSANDRA-7486).
>
> I think that gaining access to the new features in 8 as we develop 3.x is
> worth losing the ability to run on a platform that will have been EOL for a
> couple months by the time we release.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>
Re: Requiring Java 8 for C* 3.0
Posted by Benedict Elliott Smith <be...@datastax.com>.
I have no position on this, but I would like to issue a word of caution to
everyone excited to use the new JDK8 features in development to please
discuss their use widely beforehand, and to consider them carefully. Many
of them are not generally useful to us (e.g. LongAdder), and may have
unexpected behaviours (e.g. hidden parallelization in streams).
On Thu, May 7, 2015 at 5:16 PM, Yuki Morishita <mo...@gmail.com> wrote:
> +1
>
> On Thu, May 7, 2015 at 11:13 AM, Jeremiah D Jordan
> <je...@datastax.com> wrote:
> > With Java 7 being EOL for free versions I am +1 on this. If you want to
> stick with 7, you can always keep running 2.1.
> >
> >> On May 7, 2015, at 11:09 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> >>
> >> We discussed requiring Java 8 previously and decided to remain Java
> >> 7-compatible, but at the time we were planning to release 3.0 before
> Java 7
> >> EOL. Now that 8099 and increased emphasis on QA have delayed us past
> Java
> >> 7 EOL, I think it's worth reopening this discussion.
> >>
> >> If we require 8, then we can use lambdas, LongAdder, StampedLock,
> Streaming
> >> collections, default methods, etc. Not just in 3.0 but over 3.x for the
> >> next year.
> >>
> >> If we don't, then people can choose whether to deploy on 7 or 8 -- but
> the
> >> vast majority will deploy on 8 simply because 7 is no longer supported
> >> without a premium contract with Oracle. 8 also has a more advanced G1GC
> >> implementation (see CASSANDRA-7486).
> >>
> >> I think that gaining access to the new features in 8 as we develop 3.x
> is
> >> worth losing the ability to run on a platform that will have been EOL
> for a
> >> couple months by the time we release.
> >>
> >> --
> >> Jonathan Ellis
> >> Project Chair, Apache Cassandra
> >> co-founder, http://www.datastax.com
> >> @spyced
> >
>
>
>
> --
> Yuki Morishita
> t:yukim (http://twitter.com/yukim)
>
Re: Requiring Java 8 for C* 3.0
Posted by Yuki Morishita <mo...@gmail.com>.
+1
On Thu, May 7, 2015 at 11:13 AM, Jeremiah D Jordan
<je...@datastax.com> wrote:
> With Java 7 being EOL for free versions I am +1 on this. If you want to stick with 7, you can always keep running 2.1.
>
>> On May 7, 2015, at 11:09 AM, Jonathan Ellis <jb...@gmail.com> wrote:
>>
>> We discussed requiring Java 8 previously and decided to remain Java
>> 7-compatible, but at the time we were planning to release 3.0 before Java 7
>> EOL. Now that 8099 and increased emphasis on QA have delayed us past Java
>> 7 EOL, I think it's worth reopening this discussion.
>>
>> If we require 8, then we can use lambdas, LongAdder, StampedLock, Streaming
>> collections, default methods, etc. Not just in 3.0 but over 3.x for the
>> next year.
>>
>> If we don't, then people can choose whether to deploy on 7 or 8 -- but the
>> vast majority will deploy on 8 simply because 7 is no longer supported
>> without a premium contract with Oracle. 8 also has a more advanced G1GC
>> implementation (see CASSANDRA-7486).
>>
>> I think that gaining access to the new features in 8 as we develop 3.x is
>> worth losing the ability to run on a platform that will have been EOL for a
>> couple months by the time we release.
>>
>> --
>> Jonathan Ellis
>> Project Chair, Apache Cassandra
>> co-founder, http://www.datastax.com
>> @spyced
>
--
Yuki Morishita
t:yukim (http://twitter.com/yukim)
Re: Requiring Java 8 for C* 3.0
Posted by Jeremiah D Jordan <je...@datastax.com>.
With Java 7 being EOL for free versions I am +1 on this. If you want to stick with 7, you can always keep running 2.1.
> On May 7, 2015, at 11:09 AM, Jonathan Ellis <jb...@gmail.com> wrote:
>
> We discussed requiring Java 8 previously and decided to remain Java
> 7-compatible, but at the time we were planning to release 3.0 before Java 7
> EOL. Now that 8099 and increased emphasis on QA have delayed us past Java
> 7 EOL, I think it's worth reopening this discussion.
>
> If we require 8, then we can use lambdas, LongAdder, StampedLock, Streaming
> collections, default methods, etc. Not just in 3.0 but over 3.x for the
> next year.
>
> If we don't, then people can choose whether to deploy on 7 or 8 -- but the
> vast majority will deploy on 8 simply because 7 is no longer supported
> without a premium contract with Oracle. 8 also has a more advanced G1GC
> implementation (see CASSANDRA-7486).
>
> I think that gaining access to the new features in 8 as we develop 3.x is
> worth losing the ability to run on a platform that will have been EOL for a
> couple months by the time we release.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced