Re: [VOTE] Release Apache Cassandra 4.1.0 GA

[Marianne Lyne Manaog]

Hi everyone,


Matt and I finished running all the tests for V2 with the bug fixes from
CASSANDRA-18086  and
the results for the 100 partitions are definitely better than V1. For the
larger partitions (1000, 1), the results for V2 are comparable and
overall V2 did not have any performance regression.

On Tue, Dec 6, 2022 at 4:49 PM Marianne Lyne Manaog <
marianne.man...@ieee.org> wrote:

> Here is CASSANDRA-18097
>  with the bug fix
> for the performance regression encountered with 100 partitions in V2.
>
> On Mon, Dec 5, 2022 at 2:05 PM Marianne Lyne Manaog <
> marianne.man...@ieee.org> wrote:
>
>> Following on what Matt said:
>>
>> - Here is the link to the Cassandra repo with the bugfix of wait time
>> from ms to ns:
>> https://github.com/apache/cassandra/compare/trunk...marianne-manaog:cassandra:bugfix/wait-from-ms-to-ns
>>
>> - the Paxos configuration used is:
>>
>>   paxos_contention_wait_randomizer: uniform
>>
>>   paxos_contention_min_wait: 0
>>
>>   paxos_contention_max_wait: 100ms
>>
>> - V1 and V2 have the same configurations except for paxos_variant: which
>> changes accordingly
>>
>> *Results: V1 (100 partitions)*
>>
>> - Average read: 28948
>>
>> - Standard Deviation: 416.271
>>
>> - Coefficient of variance: 1.44%
>>
>> - Average write: 19248
>>
>> - Standard Deviation:158.595
>>
>> - Coefficient of variance:0.82%
>>
>> *Results: V2 (100 partitions)*
>>
>> - Average read: 12307
>>
>> - Standard Deviation: 2367.473
>>
>> - Coefficient of variance: 19.24%
>>
>> - Average write: 5780
>>
>> - Standard Deviation: 1154.261
>>
>> - Coefficient of variance: 19.97%
>>
>>
>> On Mon, Dec 5, 2022 at 1:50 PM Matt Fleming 
>> wrote:
>>
>>> Me and Marianne are also still chasing a performance issue with Paxos v2
>>> when compared with v1. We
>>> see way more contention on v2 for a LOCAL_SERIALIZABLE workload that
>>> writes/reads to only 100
>>> partitions (v2 performs better for higher partition counts). We're still
>>> investigating what's going
>>> on.
>>>
>>> Should that be a -1 vote? I'm not sure :)
>>>
>>> On Mon, 5 Dec 2022 at 11:37, Benedict  wrote:
>>>
 -0

 CASSANDRA-18086 should probably be fixed and merged first, as Paxos v2
 will be unlikely to work well for users without it. Either that or we need
 to update NEWS.txt to mention it.

 On 5 Dec 2022, at 11:01, Aleksey Yeshchenko  wrote:

 +1

 On 5 Dec 2022, at 10:17, Benjamin Lerer  wrote:

 +1

 Le lun. 5 déc. 2022 à 11:02, Berenguer Blasi 
 a écrit :

> +1
> On 5/12/22 10:53, guo Maxwell wrote:
>
> +1
>
> Mick Semb Wever 于2022年12月5日 周一下午5:33写道：
>
>>
>> Proposing the test build of Cassandra 4.1.0 GA for release.
>>
>> sha1: b807f97b37933fac251020dbd949ee8ef245b158
>> Git:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1281/org/apache/cassandra/cassandra-all/4.1.0/
>>
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/4.1.0/
>>
>> The vote will be open for 72 hours (longer if needed). Everyone who
>> has tested the build is invited to vote. Votes by PMC members are
>> considered binding. A vote passes if there are at least three binding +1s
>> and no -1's.
>>
>> [1]: CHANGES.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.1.0-tentative
>> [2]: NEWS.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.1.0-tentative
>>
> --
> you are the apple of my eye !
>
>

Compatibility with RHEL8.6

[Prince Sonu (EXT) via dev]

Hello Team
Can you Please let me know that Apache Cassandra version 3.11.13


is Compatibility with RHEL8.6 or not, if no then Please tell me which version 
Support RHEL 8.6.


Thanks
Prince Kr Sonu

JDK 20 Rampdown Phase 1 & Valhalla LW4 Early-Access builds

[David Delabassee]

Welcome to the final OpenJDK Quality Outreach update for 2022!

JDK 20, scheduled for General Availability on March 21 2023, is now in 
Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 20 [2] 
feature set is frozen (see below the final list of JEPs integrated into 
JDK 20) and only low-risk enhancements might still be considered. The 
coming weeks should be used to identify and resolve as many issues as 
possible, i.e. before JDK 20 enters the Release Candidates phase in 
early February 2023.



## JDK 20 Early-Access builds

The latest Early-Access (builds 27) are available [2] with the Release 
Notes here [3]. Those builds are provided under the GNU GPL v2, with the 
Classpath Exception.


### JEPs integrated into JDK 20:

JEP 429: Scoped Values (Incubator)
JEP 432: Record Patterns (2nd Preview)
JEP 433: Pattern Matching for switch (4th Preview)
JEP 434: Foreign Function & Memory API (2nd Preview)
JEP 436: Virtual Threads (2nd Preview)
JEP 437: Structured Concurrency (2nd Incubator)

[1] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html
[2] https://jdk.java.net/20/
[3] https://jdk.java.net/20/release-notes


### Changes in recent JDK 20 builds that may be of interest:

 Build 27:
- JDK-8297794: Deprecate JMX Management Applets for Removal
- JDK-8297118: Change IncompatibleClassChangeError to MatchException for 
exhaustive switch statements and switch expressions

- JDK-8294047: HttpResponseInputStream swallows interrupts
- JDK-8281236: (D)TLS key exchange named groups
- JDK-8280798: com.sun.jdi.ObjectReference::setValue spec should 
prohibit any final field modification

- JDK-8295350: JFR: Add stop methods for recording streams
- JDK-8295044: Implementation of Foreign Function and Memory API (2nd 
Preview)

- JDK-8296896: Change virtual Thread.yield to use external submit
- JDK-8297804: (tz) Update Timezone Data to 2022g
- JDK-8295803: Console should be usable in jshell and other environments
- JDK-828: Implementation of Scoped Values (Incubator)
- JDK-8296672: Implementation of Virtual Threads (2nd Preview)

 Build 26:
- JDK-8297276: Remove thread text from Subject.current
- JDK-8297030: Reduce Default Keep-Alive Timeout Value for httpclient
- JDK-8247645: ChaCha20 Intrinsics

 Build 25:
- JDK-8296472: Remove ObjectLocker around 
appendToClassPathForInstrumentation call
- JDK-8290313: Produce warning when user specified java.io.tmpdir 
directory doesn't exist
- JDK-8288717: Add a means to close idle connections in HTTP/2 
connection pool

- JDK-8288047: Accelerate Poly1305 on x86_64 using AVX512 instructions
- JDK-8059632: Method reference compilation uses incorrect qualifying type
- JDK-8297161: Add additional Service Attributes to Standard Algorithm 
Names guide

- JDK-8294073: Performance improvement for message digest implementations

 Build 24:
- JDK-8294731: Improve multiplicative inverse for secp256r1 implementation
- JDK-8296715: CLDR v42 update for tzdata 2022f
- JDK-8296958: [JVMCI] add API for retrieving ConstantValue attributes

 Build 23:
- JDK-8296226: Add constructors (String,Throwable) and (Throwable) to 
InvalidParameterException
- JDK-8295673: Deprecate and disable legacy parallel class loading 
workaround for non-parallel-capable class loaders

- JDK-8294241: Deprecate URL public constructors
- JDK-8289689: (fs) Re-examine the need for normalization to Unicode 
Normalization Format D (macOS)

- JDK-8279164: Disable TLS_ECDH_* cipher suites
- JDK-8178355: IdentityHashMap uses identity-based comparison for values 
everywhere except remove(K,V) and replace(K,V,V)

- JDK-8296108: (tz) Update Timezone Data to 2022f


## Heads-up - JDK 21: First Early-Access Builds

When JDK 20 entered RDP1 [4], the JDK mainline [5] was (a) forked into a 
JDK 20 stabilization repository [6], and (b) set to JDK 21. As a 
consequence, the first JDK 21 Early-Access builds have been published [7].


[4] https://mail.openjdk.org/pipermail/jdk-dev/2022-December/007233.html
[5] https://github.com/openjdk/jdk
[6] https://github.com/openjdk/jdk20
[7] https://jdk.java.net/21/


## Heads-up - Valhalla: LW4 Early-Access Builds

Valhalla LW4 early-access builds have been published [8], those builds 
are primarily focused on implementing the Value Objects JEP draft [9]. 
For additional details on those EA builds, make sure to read these LW4 
release notes [10]. For a more hands-on introduction to Value Object, 
you can watch the latest JEP Café: Java Value Objects in Action [11]. 
Interested developers are encouraged to explore the performance and 
migration impact of value objects on their applications, and to provide 
feedback to the valhalla-dev [12] mailing list.


[8] https://jdk.java.net/valhalla/
[9] https://openjdk.org/jeps/8277163
[10] https://openjdk.org/projects/valhalla/early-access
[11] https://inside.java/2022/12/06/jepcafe15/
[12] https://mail.openjdk.org/pipermail/valhalla-dev/


## Heads-up - Generational ZGC: New Early-Access Builds

New Generati

Re: [DISCUSSION] New dependencies for SAI CEP-7

[Mike Adamson]

>
> Can you talk more about why?  There are several ways to do random testing
> in-tree ATM, so wondering why we need another one


I can see one mechanism for random testing in-tree. That is the Simulator
but that seems primarily involved in the random orchestration of
operations. My apologies if I have simplified its significance. Apart from
that, I can only see different usages of Random in unit tests. I admit I
have not looked beyond this at dtests.

The random testing in SAI is more focussed on the behaviour of the
low-level index structures and flow of data to / from these. Using randomly
generated values in tests has proved invaluable in highlighting edge
conditions in the code. This above library was only added to provide us
with a rich set of random generators. I am happy to look at removing this
library if its inclusion is contentious.


On Mon, 12 Dec 2022 at 19:41, David Capwell  wrote:

> com.carrotsearch.randomizedtesting.randomizedtesting-runner 2.1.2 - test
> dependency
>
>
> Can you talk more about why?  There are several ways to do random testing
> in-tree ATM, so wondering why we need another one
>
>
> On Dec 8, 2022, at 6:51 AM, Mike Adamson  wrote:
>
> Hi,
>
> I wanted to discuss the addition of the following dependencies for CEP-7.
> The dependencies are:
>
> org.apache.lucene.lucene-core 7.5.0
> org.apache.lucene.lucene-analyzers-common 7.5.0
> com.carrotsearch.randomizedtesting.randomizedtesting-runner 2.1.2 - test
> dependency
>
> Lucene is an apache project so is licensed APL2. Carrotsearch is not an
> apache project but is licensed APL2
>
> We are also removing the dependency
> on com.github.rholder.snowball-stemmer. This library is used by SASI
> stemming filters but a later version of the same library is available in
> the lucene libraries.
>
> Does anyone have any concerns about these changes?
>
> Mike Adamson
>
>
>

-- 
[image: DataStax Logo Square]  *Mike Adamson*
Engineering

+1 650 389 6000 <16503896000> | datastax.com 
Find DataStax Online: [image: LinkedIn Logo]

   [image: Facebook Logo]

   [image: Twitter Logo]    [image: RSS Feed]
   [image: Github Logo]

[RELEASE] Apache Cassandra 4.1.0 GA released

[Mick Semb Wever]

The Cassandra team is pleased to announce the GA release of Apache
Cassandra version 4.1.0.

Apache Cassandra is a fully distributed database. It is the right choice
when you need scalability and high availability without compromising
performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download
section:

 http://cassandra.apache.org/download/

This version is the first GA release of the 4.1 series. As always, please
pay attention to the release notes[2] and Let us know[3] if you were to
encounter any problem.

[WARNING] Debian and RedHat package repositories have moved! Debian
/etc/apt/sources.list.d/cassandra.sources.list and RedHat
/etc/yum.repos.d/cassandra.repo files must be updated to the new repository
URLs. For Debian it is now https://debian.cassandra.apache.org . For RedHat
it is now https://redhat.cassandra.apache.org/41x/ .

[SOCIAL MEDIA] Dev community, FYI this is the social media guide to
help/include you if you have not been in the loop. Constantia has been
amazing, and many of you would be aware of all this already. These
activities all already are assigned to folk. It's shared here so you know
the amount of effort and coordination that's happening in parallel to this
launch.
https://docs.google.com/document/d/1OrfH9wtQjkBHo1-1SxpiMP0g_6CLSApmrAhZdzNvjXo/edit?usp=sharing


Enjoy!

[1]: CHANGES.txt
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.1.0
[2]: NEWS.txt
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.1.0
[3]: https://issues.apache.org/jira/browse/CASSANDRA

Re: [DISCUSSION] New dependencies for SAI CEP-7

[Caleb Rackliffe]

We need random generators no matter what for these tests, so I think what
we need to decide is whether to continue to use Carrot or migrate those to
QuickTheories, along the lines of what we have now in
org.apache.cassandra.utils.Generators.

When it comes to a library like this, the thing I would optimize for is how
much it already provides (and therefore how much we need to write and
maintain ourselves). If you look at something like NumericTypeSortingTest
in the 18058 branch , it's
pretty compact w/ Carrot's RandomizedTest in use, but I suppose it could
also use IntegersDSL from QT...

(Not that it matters, but just for reference, we do use
com.carrotsearch.hppc already.)

On Tue, Dec 13, 2022 at 10:14 AM Mike Adamson  wrote:

> Can you talk more about why?  There are several ways to do random testing
>> in-tree ATM, so wondering why we need another one
>
>
> I can see one mechanism for random testing in-tree. That is the Simulator
> but that seems primarily involved in the random orchestration of
> operations. My apologies if I have simplified its significance. Apart from
> that, I can only see different usages of Random in unit tests. I admit I
> have not looked beyond this at dtests.
>
> The random testing in SAI is more focussed on the behaviour of the
> low-level index structures and flow of data to / from these. Using randomly
> generated values in tests has proved invaluable in highlighting edge
> conditions in the code. This above library was only added to provide us
> with a rich set of random generators. I am happy to look at removing this
> library if its inclusion is contentious.
>
>
> On Mon, 12 Dec 2022 at 19:41, David Capwell  wrote:
>
>> com.carrotsearch.randomizedtesting.randomizedtesting-runner 2.1.2 - test
>> dependency
>>
>>
>> Can you talk more about why?  There are several ways to do random testing
>> in-tree ATM, so wondering why we need another one
>>
>>
>> On Dec 8, 2022, at 6:51 AM, Mike Adamson  wrote:
>>
>> Hi,
>>
>> I wanted to discuss the addition of the following dependencies for CEP-7.
>> The dependencies are:
>>
>> org.apache.lucene.lucene-core 7.5.0
>> org.apache.lucene.lucene-analyzers-common 7.5.0
>> com.carrotsearch.randomizedtesting.randomizedtesting-runner 2.1.2 - test
>> dependency
>>
>> Lucene is an apache project so is licensed APL2. Carrotsearch is not an
>> apache project but is licensed APL2
>>
>> We are also removing the dependency
>> on com.github.rholder.snowball-stemmer. This library is used by SASI
>> stemming filters but a later version of the same library is available in
>> the lucene libraries.
>>
>> Does anyone have any concerns about these changes?
>>
>> Mike Adamson
>>
>>
>>
>
> --
> [image: DataStax Logo Square]  *Mike Adamson*
> Engineering
>
> +1 650 389 6000 <16503896000> | datastax.com 
> Find DataStax Online: [image: LinkedIn Logo]
> 
>[image: Facebook Logo]
> 
>[image: Twitter Logo]    [image: RSS
> Feed]    [image: Github Logo]
> 
>
>

Re: [DISCUSSION] New dependencies for SAI CEP-7

[David Capwell]

Speaking to Caleb in Slack, so putting the main comments I have there here…

I am not -1 on this new dependency, but more asking what we should use for 
random testing moving forward…. ATM we have the following:

1) QuickTheories - I feel like I am the only user at this point…
2) 1-off - many reinvent random testing for a specific class; using Random, 
ThreadLocalRandom, UUID.randomUUID(), and lang3 classes (such as 
org.apache.commons.lang3.RandomUtils)
3) Harry - even though the main API is for cluster testing, this is built 
on-top of random generation so could be used for low level random testing (just 
less fleshed out for this use-case)
4) Simulator - same as Harry, built on top of a random generator and not 
fleshed out for low level random testing

Another reason I ask this is I have a fuzz testing that I have developed for 
Accord testing that generates random valid CQL statements to make sure we “do 
the right thing” and have been struggling with the question “where do I put 
this” and “what random do I use?”.  I built this off QuickTheories as I have a 
lot of utilities for building all supported Tables and Types so really quick do 
bootstrap, and every other random testing thing we have are less fleshed out… 
so if we add yet another random testing library what “should” we be using?  Do 
we build on-top of it to get to the same level QuickTheory is (see 
org.apache.cassandra.utils.Generators, 
org.apache.cassandra.utils.CassandraGenerators, and 
org.apache.cassandra.utils.AbstractTypeGenerators)?

> On Dec 13, 2022, at 9:21 AM, Caleb Rackliffe  wrote:
> 
> We need random generators no matter what for these tests, so I think what we 
> need to decide is whether to continue to use Carrot or migrate those to 
> QuickTheories, along the lines of what we have now in 
> org.apache.cassandra.utils.Generators.
> 
> When it comes to a library like this, the thing I would optimize for is how 
> much it already provides (and therefore how much we need to write and 
> maintain ourselves). If you look at something like NumericTypeSortingTest in 
> the 18058 branch , it's pretty 
> compact w/ Carrot's RandomizedTest in use, but I suppose it could also use 
> IntegersDSL from QT...
> 
> (Not that it matters, but just for reference, we do use com.carrotsearch.hppc 
> already.)
> 
> On Tue, Dec 13, 2022 at 10:14 AM Mike Adamson  > wrote:
> Can you talk more about why?  There are several ways to do random testing 
> in-tree ATM, so wondering why we need another one
> 
> I can see one mechanism for random testing in-tree. That is the Simulator but 
> that seems primarily involved in the random orchestration of operations. My 
> apologies if I have simplified its significance. Apart from that, I can only 
> see different usages of Random in unit tests. I admit I have not looked 
> beyond this at dtests.
> 
> The random testing in SAI is more focussed on the behaviour of the low-level 
> index structures and flow of data to / from these. Using randomly generated 
> values in tests has proved invaluable in highlighting edge conditions in the 
> code. This above library was only added to provide us with a rich set of 
> random generators. I am happy to look at removing this library if its 
> inclusion is contentious.
> 
> 
> On Mon, 12 Dec 2022 at 19:41, David Capwell  > wrote:
>> com.carrotsearch.randomizedtesting.randomizedtesting-runner 2.1.2 - test 
>> dependency
> 
> Can you talk more about why?  There are several ways to do random testing 
> in-tree ATM, so wondering why we need another one
> 
> 
>> On Dec 8, 2022, at 6:51 AM, Mike Adamson > > wrote:
>> 
>> Hi,
>> 
>> I wanted to discuss the addition of the following dependencies for CEP-7. 
>> The dependencies are:
>> 
>> org.apache.lucene.lucene-core 7.5.0
>> org.apache.lucene.lucene-analyzers-common 7.5.0
>> com.carrotsearch.randomizedtesting.randomizedtesting-runner 2.1.2 - test 
>> dependency
>> 
>> Lucene is an apache project so is licensed APL2. Carrotsearch is not an 
>> apache project but is licensed APL2
>> 
>> We are also removing the dependency on com.github.rholder.snowball-stemmer. 
>> This library is used by SASI stemming filters but a later version of the 
>> same library is available in the lucene libraries.
>> 
>> Does anyone have any concerns about these changes?
>> 
>> Mike Adamson
> 
> 
> 
> -- 
>    Mike Adamson
> Engineering
> 
> +1 650 389 6000  | datastax.com 
> Find DataStax Online:  
> 
> 
> 

Re: [DISCUSSION] New dependencies for SAI CEP-7

[Josh McKenzie]

Whatever we decide on, let's make sure we document it so newcomers on the 
project (or really anyone new to property based testing) can better discover 
those things.

https://cassandra.apache.org/_/development/testing.html

On Tue, Dec 13, 2022, at 1:08 PM, David Capwell wrote:
> Speaking to Caleb in Slack, so putting the main comments I have there here…
> 
> I am not -1 on this new dependency, but more asking what we should use for 
> random testing moving forward…. ATM we have the following:
> 
> 1) QuickTheories - I feel like I am the only user at this point…
> 2) 1-off - many reinvent random testing for a specific class; using Random, 
> ThreadLocalRandom, UUID.randomUUID(), and lang3 classes (such as 
> org.apache.commons.lang3.RandomUtils)
> 3) Harry - even though the main API is for cluster testing, this is built 
> on-top of random generation so could be used for low level random testing 
> (just less fleshed out for this use-case)
> 4) Simulator - same as Harry, built on top of a random generator and not 
> fleshed out for low level random testing
> 
> Another reason I ask this is I have a fuzz testing that I have developed for 
> Accord testing that generates random valid CQL statements to make sure we “do 
> the right thing” and have been struggling with the question “where do I put 
> this” and “what random do I use?”.  I built this off QuickTheories as I have 
> a lot of utilities for building all supported Tables and Types so really 
> quick do bootstrap, and every other random testing thing we have are less 
> fleshed out… so if we add yet another random testing library what “should” we 
> be using?  Do we build on-top of it to get to the same level QuickTheory is 
> (see org.apache.cassandra.utils.Generators, 
> org.apache.cassandra.utils.CassandraGenerators, and 
> org.apache.cassandra.utils.AbstractTypeGenerators)?
> 
>> On Dec 13, 2022, at 9:21 AM, Caleb Rackliffe  
>> wrote:
>> 
>> We need random generators no matter what for these tests, so I think what we 
>> need to decide is whether to continue to use Carrot or migrate those to 
>> QuickTheories, along the lines of what we have now in 
>> org.apache.cassandra.utils.Generators.
>> 
>> When it comes to a library like this, the thing I would optimize for is how 
>> much it already provides (and therefore how much we need to write and 
>> maintain ourselves). If you look at something like NumericTypeSortingTest in 
>> the 18058 branch , it's pretty 
>> compact w/ Carrot's RandomizedTest in use, but I suppose it could also use 
>> IntegersDSL from QT...
>> 
>> (Not that it matters, but just for reference, we do use 
>> com.carrotsearch.hppc already.)
>> 
>> On Tue, Dec 13, 2022 at 10:14 AM Mike Adamson  wrote:
 Can you talk more about why?  There are several ways to do random testing 
 in-tree ATM, so wondering why we need another one
>>> 
>>> I can see one mechanism for random testing in-tree. That is the Simulator 
>>> but that seems primarily involved in the random orchestration of 
>>> operations. My apologies if I have simplified its significance. Apart from 
>>> that, I can only see different usages of Random in unit tests. I admit I 
>>> have not looked beyond this at dtests.
>>> 
>>> The random testing in SAI is more focussed on the behaviour of the 
>>> low-level index structures and flow of data to / from these. Using randomly 
>>> generated values in tests has proved invaluable in highlighting edge 
>>> conditions in the code. This above library was only added to provide us 
>>> with a rich set of random generators. I am happy to look at removing this 
>>> library if its inclusion is contentious.
>>> 
>>> 
>>> On Mon, 12 Dec 2022 at 19:41, David Capwell  wrote:
> com.carrotsearch.randomizedtesting.randomizedtesting-runner 2.1.2 - test 
> dependency
 
 Can you talk more about why?  There are several ways to do random testing 
 in-tree ATM, so wondering why we need another one
 
 
> On Dec 8, 2022, at 6:51 AM, Mike Adamson  wrote:
> 
> Hi,
> 
> I wanted to discuss the addition of the following dependencies for CEP-7. 
> The dependencies are:
> 
> org.apache.lucene.lucene-core 7.5.0
> org.apache.lucene.lucene-analyzers-common 7.5.0
> com.carrotsearch.randomizedtesting.randomizedtesting-runner 2.1.2 - test 
> dependency
> 
> Lucene is an apache project so is licensed APL2. Carrotsearch is not an 
> apache project but is licensed APL2
> 
> We are also removing the dependency on 
> com.github.rholder.snowball-stemmer. This library is used by SASI 
> stemming filters but a later version of the same library is available in 
> the lucene libraries.
> 
> Does anyone have any concerns about these changes?
> 
> Mike Adamson
> 
 
>>> 
>>> 
>>> -- 
>>> DataStax Logo Square 
>>> *Mike Adamson*
>>> Engineering
>>> +1 650 389 6000  | dat

Re: [DISCUSSION] Cassandra's code style and source code analysis

[Miklosovic, Stefan]

Hi Maxim,

yes I will help you to review that.

The approach you outlined sounds reasonable to me by I do not think we can 
merge this based on my opinion only. I would welcome more developers to discuss 
this.

Another angle I forgot to mention is that this is quite a big patch and there 
are quite big pieces of work coming, being it CEP-15, for example. So I am 
trying to figure out if we are ok to just merge this work first and devs doing 
CEP-15 will need to rework their imports or we merge this after them so we will 
fix their stuff. I do not know what is more preferable.

I do not think that the order of imports as we having right now is the same we 
want to go with. Check Benedict's comment here (1). I agree that the current 
ordering is strange. Like, why is there this "org.cliffc.high_scale_lib" import 
in particular? That seems to be completely arbitrary here (or it has some 
intrinsic logic but I do not see it nor that decision is nowhere to find 
documented).

We need to gather more feedback here. I ll try to take a look at other Apache 
projects how their import order is.

Regards

Regards

(1) https://issues.apache.org/jira/browse/CASSANDRA-17925


From: Maxim Muzafarov 
Sent: Monday, December 12, 2022 17:13
To: dev@cassandra.apache.org
Subject: Re: [DISCUSSION] Cassandra's code style and source code analysis

NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.




> Technically it can be two commits which would be merged / pushed at once.

I'll prepare a new pull request containing both of the changes. My
previous experience says me that it's really hard to find a reviewer
who will be able to go through huge pull requests, that's why
initially I've split this into AvoidStarImport and CustomImportOrder
rules. So, if you'll help with the review I'm happy to proceed the way
you suggested :-)

> One thing which needs extra care for ordering imports is that if you order it 
> in IDEA by right-clicking on a package and choosing organising imports, it 
> will remove special comments

You're right, but this is quite unusual behaviour for me and this
seems to be a bug, that hasn't been fixed for a long time [1]. I've
tested the same thing for Eclipse and NetBeans and `optimize imports`
working there as we expect (no comments removes), so the issue exists
only for the IntelliJ IDEA [1].
Despite all of that, we are still on the safe side here - if these
comments will be removed by the `optimized import` procedure the build
with checkstyle will fail.

> I think this is a great time to revisit this ordering.

I would say that the imports order is pretty good (probably, except
for the blank lines) and the imports order is not as important as it
is important that it be the same in all files and automation `optimize
imports`.
I suggest going through a "minimum change" strategy here. The IntelliJ
IDEA has the following configuration with the imports order that most
of the classes already fit:

import java
import javax
[blank line]
import com.google.common
import org.apache.log4j
import org.apache.commons
import org.cliffc.high_scale_lib
import org.junit
import org.slf4j
[blank line]
import all other imports
[blank line]
import static all other imports

We can update the documentation page [2] with this order and implement
the same for NetBeans and Eclipse IDE configuration files as well as
for the checkstyle config.


If everyone is OK with the plan above I'll prepare everything for it.

Suggested summary:
- use current IntelliJ IDEA imports order as defaults for other IDEs;
- update the documentation page;
- prepare a single pull request with AvoidStarImport and CustomImportOrder;



[1] 
https://youtrack.jetbrains.com/issue/IDEA-128133/Optimize-Imports-disregards-line-comments
[2] https://cassandra.apache.org/_/development/code_style.html

On Sun, 11 Dec 2022 at 00:03, Miklosovic, Stefan
 wrote:
>
> Should the source code obey the AvoidStarImport rule?
>
> yes
>
>  Should we implement AvoidStarImport and CustomImportOrder in a
> single pull request or do it one by one?
>
> Technically it can be two commits which would be merged / pushed at once.
>
> One thing which needs extra care for ordering imports is that if you order it 
> in IDEA by right-clicking on a package and choosing organising imports, it 
> will remove special comments which are put at the end of the import 
> statement. We need to be sure you put them back.  Look at changes in 
> CASSANDRA-17055. We need to preserve this.
>
> Also, we need to be sure that the importing style can be (roughly) set in 
> each major IDE. (eclipse / netbeans / idea) so if we require some import 
> style it can be set in IDE like that. I do not know if we have any strong 
> preference when it comes to this but it definitely does not hurt.
>
> Also, I see that the current import style is
>
> java
> [blank line]
> com.google.