Empty partition keys allowed in MV, but not in normal table
Hi,
Given the following table:
cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table t (p text, c int, v text, primary key (p));
cqlsh> use ks;
The following fails:
cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may not be
empty"
However, MVs don't appear to have this restriction:
create materialized view mv as select * from t where v is not null and p is not
null and c is not null primary key (v, p);
insert into t (p, c, v) values ('a', 2, '');
select * from mv;
v | p | c
---+---+---
| a | 2
I guess this is because an empty value can't be distinguished from null at the protocol level, but this distinction can
be made internally.
I think the behavior should be made consistent, if nothing else because
querying the MV for the empty key is impossible:
cqlsh:ks> select * from mv where v = '';
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may not be
empty"
Thoughts?
Thanks,
Duarte
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
On Fri, 23 Mar 2018 15:52:51 +, you wrote: >Java 8 was marked as EOL in the middle of last year, I hope we wouldn't >require it for Cassandra 4. At this point I feel like we should already be >targeting Java 10 at a minimum. Given that the last messages indicated aiming Cassandra 4 for the 3rd/4th quarter it is a bit of quandary. Perhaps the answer is to aim for Q4 by for now building and testing on Java 10, and then when Java 11 is released switching to that for testing only, with the hope of getting Cassandra 4 out a couple of months after Java 11 (assuming Java 11 is on time, but one of the hoped for effects of a 6 month cadence is you don't run into big changes that delay things). With Java 11 you then get the latest LTS which Oracle and I would assume Red Hat and other supporting for years instead of months. Essentially, if organizations are going to go through the process of a significant upgrade in Cassandra then let them at least at the same time have the option of getting onto the lastest LTS Java so they can mimize future disruptions. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
question on running cassandra-dtests
Hi All, I am trying to setup and run Cassandra-dtests so that I can write some tests for a JIRA ticket I have been working on. This is the repo I am using: https://github.com/apache/cassandra-dtest I followed all the instructions and installed dependencies. However, when I run "pytest -cassandra-dir= It throws the error "could not load /conftest.py. I checked that this file (conftest.py) exists in Cassandra-dtest source root and I'm not sure why it cannot find it. Does anyone have any idea what might be going wrong here? I haven't used dtests before so I wonder if I'm missing something here. Thanks, Preetika
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
I am now thinking that aligning to the major JDK release that is for-pay three years if you want it is the best strategy. What I think will happen is that there will be a consortium that maintains/backports that release level independent of oracle, if only to spite them. I'm thinking IBM, Azul, etc will do so. Fundamentally the project doesn't really care about the churn in the language spec from new releases, except for breaking changes for a JDK8-ish codebase, which should be, what, Jigsaw? What the project cares about are security patches and JVM advancements. JVM advancements will probably trickle into the long term non-Oracle (assuming it appears) if it is important enough. On Fri, Mar 23, 2018 at 11:16 AM, Jonathan Haddad wrote: > I suppose given the short lifetime of each Java release you could argue > we're always close to EOL. I feel like we shouldn't ship with a version > that is currently EOL. > > Coming up with a policy for all upcoming releases may also be incredibly > difficult. 6 months java releases could pan out like Tick Tock and reveal > itself to be a fun idea with some really bad consequences, and it goes away > after Java 12. Impossible to tell. How about we figure out the next > release and get a little experience under our belts with their new release > schedule before we try to make long term decisions? > > On Fri, Mar 23, 2018 at 9:08 AM Josh McKenzie > wrote: > > > > At this point I feel like we should already be > > > targeting Java 10 at a minimum. > > Barring some surprises from other people supporting 10 longer-term, > > wouldn't that be coupling C*'s 4.0 release with a runtime that's > > likely EOL shortly after? > > > > On Fri, Mar 23, 2018 at 11:52 AM, Jonathan Haddad > > wrote: > > > Java 8 was marked as EOL in the middle of last year, I hope we wouldn't > > > require it for Cassandra 4. At this point I feel like we should > already > > be > > > targeting Java 10 at a minimum. > > > > > > Personally I'd prefer not to tie our releases to any vendor / product / > > > package's release schedule. > > > > > > > > > On Fri, Mar 23, 2018 at 6:49 AM Jason Brown > > wrote: > > > > > >> I'm coming to be on-board with #3. > > >> > > >> One thing to watch out for (we can't account for it now) is how our > > >> dependencies choose to move forward. If we need to upgrade a jar > (netty, > > >> for example) due to some leak or vulnerability, and it only runs on a > > >> higher version, we may be forced to upgrade the base java version. > > Like, I > > >> said we can't possibly foresee these things, and we'll just have to > > make a > > >> hard decision if the situation arises, but just something to keep in > > mind. > > >> > > >> > > >> On Fri, Mar 23, 2018 at 5:39 AM, Josh McKenzie > > >> wrote: > > >> > > >> > > > > >> > > 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11 > later > > >> > > > >> > This seems like the best of our bad options, with the addition of > > >> > "optionally". > > >> > > > >> > > > >> > On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen < > ghenr...@gmail.com > > > > > >> > wrote: > > >> > > > >> > > On Fri, 23 Mar 2018 04:54:23 +, you wrote: > > >> > > > > >> > > >I think Michael is right. It would be impossible to make everyone > > >> follow > > >> > > >such a fast release scheme, and supporting it will be pressured > > onto > > >> the > > >> > > >various distributions, M$ and Apple. > > >> > > >On the other hand https://adoptopenjdk.net has already done a > lot > > of > > >> > the > > >> > > >work and it's already rumoured they may take up backporting of > > >> > > security/bug > > >> > > >fixes. I'd fully expect a lot of users to collaborate around this > > (or > > >> > > >similar), and there's no reason we couldn't do our part to > > contribute. > > >> > > > > >> > > A posting on Reddit yesterday from someone from adoptopenjdk > claimes > > >> > > that they will be doing LTS releases starting with Java 11, and > > there > > >> > > should be updates to their website to reflect that soon: > > >> > > > > >> > > > > https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/ > > >> > > > > >> > > So I guess a wait and see to what they commit could be worthwhile. > > >> > > > > >> > > > > - > > >> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > >> > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > >> > > > > >> > > > > >> > > > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: IN restrictions are not supported on indexed columns
There are not real blocker I believe. It is just that we never implemented
it.
On Fri, Mar 23, 2018 at 6:08 PM, Dikang Gu wrote:
> Hello C* developers:
>
> I have one question, does anyone know why we can not support the IN
> restrictions on indexed columns? Is it just because no one is working it?
> Or are there any other reasons?
>
> Below is an example query:
>
>
> cqlsh:ks1> describe keyspace;
>
> CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class': '
> org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+--+--+---
>1 |1 |1 | 1
>1 |2 |1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow
> filtering;
> *InvalidRequest: Error from server: code=2200 [Invalid query] message="IN
> restrictions are not supported on indexed columns"*
> cqlsh:ks1>
> =
>
> Thanks
>
>
> --
> Dikang
>
IN restrictions are not supported on indexed columns
Hello C* developers:
I have one question, does anyone know why we can not support the IN
restrictions on indexed columns? Is it just because no one is working it?
Or are there any other reasons?
Below is an example query:
cqlsh:ks1> describe keyspace;
CREATE KEYSPACE ks1 WITH replication = {'class': 'SimpleStrategy',
'replication_factor': '1'} AND durable_writes = true;
CREATE TABLE ks1.t1 (
key int,
col1 int,
col2 int,
value int,
PRIMARY KEY (key, col1, col2)
) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': '
org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';
cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
key | col1 | col2 | value
-+--+--+---
1 |1 |1 | 1
1 |2 |1 | 3
(2 rows)
cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow
filtering;
*InvalidRequest: Error from server: code=2200 [Invalid query] message="IN
restrictions are not supported on indexed columns"*
cqlsh:ks1>
=
Thanks
--
Dikang
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
I suppose given the short lifetime of each Java release you could argue we're always close to EOL. I feel like we shouldn't ship with a version that is currently EOL. Coming up with a policy for all upcoming releases may also be incredibly difficult. 6 months java releases could pan out like Tick Tock and reveal itself to be a fun idea with some really bad consequences, and it goes away after Java 12. Impossible to tell. How about we figure out the next release and get a little experience under our belts with their new release schedule before we try to make long term decisions? On Fri, Mar 23, 2018 at 9:08 AM Josh McKenzie wrote: > > At this point I feel like we should already be > > targeting Java 10 at a minimum. > Barring some surprises from other people supporting 10 longer-term, > wouldn't that be coupling C*'s 4.0 release with a runtime that's > likely EOL shortly after? > > On Fri, Mar 23, 2018 at 11:52 AM, Jonathan Haddad > wrote: > > Java 8 was marked as EOL in the middle of last year, I hope we wouldn't > > require it for Cassandra 4. At this point I feel like we should already > be > > targeting Java 10 at a minimum. > > > > Personally I'd prefer not to tie our releases to any vendor / product / > > package's release schedule. > > > > > > On Fri, Mar 23, 2018 at 6:49 AM Jason Brown > wrote: > > > >> I'm coming to be on-board with #3. > >> > >> One thing to watch out for (we can't account for it now) is how our > >> dependencies choose to move forward. If we need to upgrade a jar (netty, > >> for example) due to some leak or vulnerability, and it only runs on a > >> higher version, we may be forced to upgrade the base java version. > Like, I > >> said we can't possibly foresee these things, and we'll just have to > make a > >> hard decision if the situation arises, but just something to keep in > mind. > >> > >> > >> On Fri, Mar 23, 2018 at 5:39 AM, Josh McKenzie > >> wrote: > >> > >> > > > >> > > 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11 later > >> > > >> > This seems like the best of our bad options, with the addition of > >> > "optionally". > >> > > >> > > >> > On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen > > >> > wrote: > >> > > >> > > On Fri, 23 Mar 2018 04:54:23 +, you wrote: > >> > > > >> > > >I think Michael is right. It would be impossible to make everyone > >> follow > >> > > >such a fast release scheme, and supporting it will be pressured > onto > >> the > >> > > >various distributions, M$ and Apple. > >> > > >On the other hand https://adoptopenjdk.net has already done a lot > of > >> > the > >> > > >work and it's already rumoured they may take up backporting of > >> > > security/bug > >> > > >fixes. I'd fully expect a lot of users to collaborate around this > (or > >> > > >similar), and there's no reason we couldn't do our part to > contribute. > >> > > > >> > > A posting on Reddit yesterday from someone from adoptopenjdk claimes > >> > > that they will be doing LTS releases starting with Java 11, and > there > >> > > should be updates to their website to reflect that soon: > >> > > > >> > > > https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/ > >> > > > >> > > So I guess a wait and see to what they commit could be worthwhile. > >> > > > >> > > > - > >> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > >> > > For additional commands, e-mail: dev-h...@cassandra.apache.org > >> > > > >> > > > >> > > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
> At this point I feel like we should already be > targeting Java 10 at a minimum. Barring some surprises from other people supporting 10 longer-term, wouldn't that be coupling C*'s 4.0 release with a runtime that's likely EOL shortly after? On Fri, Mar 23, 2018 at 11:52 AM, Jonathan Haddad wrote: > Java 8 was marked as EOL in the middle of last year, I hope we wouldn't > require it for Cassandra 4. At this point I feel like we should already be > targeting Java 10 at a minimum. > > Personally I'd prefer not to tie our releases to any vendor / product / > package's release schedule. > > > On Fri, Mar 23, 2018 at 6:49 AM Jason Brown wrote: > >> I'm coming to be on-board with #3. >> >> One thing to watch out for (we can't account for it now) is how our >> dependencies choose to move forward. If we need to upgrade a jar (netty, >> for example) due to some leak or vulnerability, and it only runs on a >> higher version, we may be forced to upgrade the base java version. Like, I >> said we can't possibly foresee these things, and we'll just have to make a >> hard decision if the situation arises, but just something to keep in mind. >> >> >> On Fri, Mar 23, 2018 at 5:39 AM, Josh McKenzie >> wrote: >> >> > > >> > > 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11 later >> > >> > This seems like the best of our bad options, with the addition of >> > "optionally". >> > >> > >> > On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen >> > wrote: >> > >> > > On Fri, 23 Mar 2018 04:54:23 +, you wrote: >> > > >> > > >I think Michael is right. It would be impossible to make everyone >> follow >> > > >such a fast release scheme, and supporting it will be pressured onto >> the >> > > >various distributions, M$ and Apple. >> > > >On the other hand https://adoptopenjdk.net has already done a lot of >> > the >> > > >work and it's already rumoured they may take up backporting of >> > > security/bug >> > > >fixes. I'd fully expect a lot of users to collaborate around this (or >> > > >similar), and there's no reason we couldn't do our part to contribute. >> > > >> > > A posting on Reddit yesterday from someone from adoptopenjdk claimes >> > > that they will be doing LTS releases starting with Java 11, and there >> > > should be updates to their website to reflect that soon: >> > > >> > > https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/ >> > > >> > > So I guess a wait and see to what they commit could be worthwhile. >> > > >> > > - >> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> > > For additional commands, e-mail: dev-h...@cassandra.apache.org >> > > >> > > >> > >> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
Java 8 was marked as EOL in the middle of last year, I hope we wouldn't require it for Cassandra 4. At this point I feel like we should already be targeting Java 10 at a minimum. Personally I'd prefer not to tie our releases to any vendor / product / package's release schedule. On Fri, Mar 23, 2018 at 6:49 AM Jason Brown wrote: > I'm coming to be on-board with #3. > > One thing to watch out for (we can't account for it now) is how our > dependencies choose to move forward. If we need to upgrade a jar (netty, > for example) due to some leak or vulnerability, and it only runs on a > higher version, we may be forced to upgrade the base java version. Like, I > said we can't possibly foresee these things, and we'll just have to make a > hard decision if the situation arises, but just something to keep in mind. > > > On Fri, Mar 23, 2018 at 5:39 AM, Josh McKenzie > wrote: > > > > > > > 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11 later > > > > This seems like the best of our bad options, with the addition of > > "optionally". > > > > > > On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen > > wrote: > > > > > On Fri, 23 Mar 2018 04:54:23 +, you wrote: > > > > > > >I think Michael is right. It would be impossible to make everyone > follow > > > >such a fast release scheme, and supporting it will be pressured onto > the > > > >various distributions, M$ and Apple. > > > >On the other hand https://adoptopenjdk.net has already done a lot of > > the > > > >work and it's already rumoured they may take up backporting of > > > security/bug > > > >fixes. I'd fully expect a lot of users to collaborate around this (or > > > >similar), and there's no reason we couldn't do our part to contribute. > > > > > > A posting on Reddit yesterday from someone from adoptopenjdk claimes > > > that they will be doing LTS releases starting with Java 11, and there > > > should be updates to their website to reflect that soon: > > > > > > https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/ > > > > > > So I guess a wait and see to what they commit could be worthwhile. > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > >
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
I'm coming to be on-board with #3. One thing to watch out for (we can't account for it now) is how our dependencies choose to move forward. If we need to upgrade a jar (netty, for example) due to some leak or vulnerability, and it only runs on a higher version, we may be forced to upgrade the base java version. Like, I said we can't possibly foresee these things, and we'll just have to make a hard decision if the situation arises, but just something to keep in mind. On Fri, Mar 23, 2018 at 5:39 AM, Josh McKenzie wrote: > > > > 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11 later > > This seems like the best of our bad options, with the addition of > "optionally". > > > On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen > wrote: > > > On Fri, 23 Mar 2018 04:54:23 +, you wrote: > > > > >I think Michael is right. It would be impossible to make everyone follow > > >such a fast release scheme, and supporting it will be pressured onto the > > >various distributions, M$ and Apple. > > >On the other hand https://adoptopenjdk.net has already done a lot of > the > > >work and it's already rumoured they may take up backporting of > > security/bug > > >fixes. I'd fully expect a lot of users to collaborate around this (or > > >similar), and there's no reason we couldn't do our part to contribute. > > > > A posting on Reddit yesterday from someone from adoptopenjdk claimes > > that they will be doing LTS releases starting with Java 11, and there > > should be updates to their website to reflect that soon: > > > > https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/ > > > > So I guess a wait and see to what they commit could be worthwhile. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
> > 3) Release 4.0 for Java 8, *optionally* branch 4.1 for Java 11 later This seems like the best of our bad options, with the addition of "optionally". On Fri, Mar 23, 2018 at 8:12 AM, Gerald Henriksen wrote: > On Fri, 23 Mar 2018 04:54:23 +, you wrote: > > >I think Michael is right. It would be impossible to make everyone follow > >such a fast release scheme, and supporting it will be pressured onto the > >various distributions, M$ and Apple. > >On the other hand https://adoptopenjdk.net has already done a lot of the > >work and it's already rumoured they may take up backporting of > security/bug > >fixes. I'd fully expect a lot of users to collaborate around this (or > >similar), and there's no reason we couldn't do our part to contribute. > > A posting on Reddit yesterday from someone from adoptopenjdk claimes > that they will be doing LTS releases starting with Java 11, and there > should be updates to their website to reflect that soon: > > https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/ > > So I guess a wait and see to what they commit could be worthwhile. > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
On Fri, 23 Mar 2018 04:54:23 +, you wrote: >I think Michael is right. It would be impossible to make everyone follow >such a fast release scheme, and supporting it will be pressured onto the >various distributions, M$ and Apple. >On the other hand https://adoptopenjdk.net has already done a lot of the >work and it's already rumoured they may take up backporting of security/bug >fixes. I'd fully expect a lot of users to collaborate around this (or >similar), and there's no reason we couldn't do our part to contribute. A posting on Reddit yesterday from someone from adoptopenjdk claimes that they will be doing LTS releases starting with Java 11, and there should be updates to their website to reflect that soon: https://www.reddit.com/r/java/comments/86ce66/java_long_term_support/ So I guess a wait and see to what they commit could be worthwhile. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
I think it's pretty safe to assume that Java 8 will stay around much longer than by the end of the year, after Oracle dropped their official maintainer role. I also think that we don't have to worry that much how exactly Java 8 is going to be supported. It's a mature enough version that I wouldn't expect significant incompatibilities between back-ports or forks. In the best case, someone will even step up taking the official maintainer role as part of the OpenJDK project. But I'm pretty sure we'll manage to keeping up supporting Java 8 for Cassandra throughout the next years, if we decide to do so. At the beginning, we've discussed the elastic search plans of supporting the newest Java release and the latest LTS release at the same time. Maybe it's a good time to get back thinking about this idea again and ask us, do we really want to support the latest Java release, even if it's a non-LTS release? Given the likely overlap of new major Java releases and continued support for already released Cassandra branches, I'd expect this to become a strain for developers and possible source of confusion for users. Do we as developers or any users really care that much about non-LTS releases in general, that we want to commit us to that? Let's assume we're only going to support Java LTS releases for now. How exactly would we want to go on from here? Keep in mind that Java 11 LTS is already scheduled for September. Let's take a look at some LTS only options: 1) Release 4.0 for Java 11 exclusively (3.11 for Java 8) Start upgrading CI to initial Java 11 release candidate, merge Robert's Java 9 patch and start fixing all incompatibility issues. Release 4.0 at some point after Java 11. This is probably the most risky option, as we can't see yet how the Java 11 adoption rate will turn out to be. In the worst case, Java 8 will still dominate for times to come and depending on Java 11 as hard requirement may hurt 4.0 adoption. 2) Release 4.0 for Java 8 + 11 Support both LTS versions for 4.0. I'd expect this to be non-trivial, but maybe Robert can share some first hand experience what would have to be done to make this possible. As described in the elastic search blog, what they plan to do is to create multi-release jars for code compiled against different versions, which is only possible starting with Java 9. We don't even have that and would still have to make sure the same code runs on both 8 and 11. 3) Release 4.0 for Java 8, branch 4.1 for Java 11 later Don't do anything yet and release 4.0 for Java 8. Keep an eye on how the situation unfolds during the next months and how fast Java 11 will be adopted by Cassandra users. Branch 4.1 for Java 11, if there's public demand and we agree that it makes sense at that point. This is basically an incremental approach to 1), but we'll end up with another branch, which we also would have to support in the future (4.0 for 8, 4.1 for 11). On 22.03.2018 23:30, Michael Shuler wrote: > As I mentioned in IRC and was pasted earlier in the thread, I believe > the easiest path is to follow the major releases of OpenJDK in the > long-term-support Linux OS releases. Currently, Debian Stable (Stretch), > Ubuntu 16.04 (Bionic (near release)), and Red Hat / CentOS 7 all have > OpenJDK 8 as the default JDK. For long-term support, they all have build > facilities in place for their supported architectures and developers > that care about security updates for users through their documented EOL > dates. > > The current deb and rpm packages for Apache Cassandra all properly > depend on OpenJDK 8, so there's really nothing to be done here, until > the project decides to implicitly depend on a JDK version not easily > installable on the major OS LTS releases. (Users of older OS versions > may need to fiddle with yum and apt sources to get OpenJDK 8, but this > is a relatively solved problem.) > > Users have the ability to deviate and set a JAVA_HOME env var to use a > custom-installed JDK of their liking, or go down the `alternatives` path > of their favorite OS. > > 1) I don't think we should be get into the business of distributing > Java, even if licensing allowed it. > 2) The OS vendors are in the business of keeping users updated with > upstream releases of Java, so there's no reason not to utilize them. > > Michael > > On 03/22/2018 05:12 PM, Jason Brown wrote: >> See the legal-discuss@ thread: >> https://mail-archives.apache.org/mod_mbox/www-legal-discuss/201803.mbox/browser >> . >> >> TL;DR jlink-based distributions are not gonna fly due to OpenJDK's license, >> so let's focus on other paths forward. >> >> >> On Thu, Mar 22, 2018 at 2:04 PM, Carl Mueller >> wrote: >> >>> Is OpenJDK really not addressing this at all? Is that because OpenJDK is >>> beholden to Oracle somehow? This is a major disservice to Apache and the >>> java ecosystem as a whole. >>> >>> When java was fully open sourced, it was supposed to free the ecosystem to >>> a large degree from Oracle. Why is OpenJDK be
