Empty partition keys allowed in MV, but not in normal table

[Duarte Nunes]

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

[Gerald Henriksen]

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

[Tyagi, Preetika]

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

[Carl Mueller]

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

[Benjamin Lerer]

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

[Dikang Gu]

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

[Josh McKenzie]

> 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

[Jonathan Haddad]

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

[Jason Brown]

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

[Josh McKenzie]

>
> 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

[Gerald Henriksen]

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

[Stefan Podkowinski]

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