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

2025-05-23 Thread Maxim Muzafarov
Hello everyone,

Bumping the topic up with an update.

The changes that include the import order reorganization are ready for review:
https://github.com/apache/cassandra/pull/2108
https://issues.apache.org/jira/browse/CASSANDRA-17925

The changes have been divided into two commits. The first commit
includes the configuration files, and the second commit includes
optimized imports. The latter will add .git-blame-ignore-revs to
exclude it from git blame. The IntelliJ IDEA code style configurations
are placed under the project's root directory. Once the changes are
merged, everyone will use the same import order for the trunk. Hot
keys to sort imports will also work out of the box.


The import order we've agreed upon:
java.*
[blank line]
javax.*
[blank line]
com.*
[blank line]
net.*
[blank line]
org.*
[blank line]
org.apache.cassandra.*
[blank line]
all other imports
[blank line]
static all other imports

On Fri, 6 Oct 2023 at 12:45, Maxim Muzafarov  wrote:
>
> Hello everyone,
>
> Some updates.
> There are issues that we have put on hold, waiting for the CEPs to be
> finalized. The java imports are one of these issues, let's do not
> forget them ^^
>
> I've created a label to track it:
> https://issues.apache.org/jira/issues/?jql=labels%20%3D%20code-polishing
>
> On Tue, 1 Aug 2023 at 10:46, Miklosovic, Stefan
>  wrote:
> >
> > I think we might wait for Accord and transactional metadata as the last big 
> > contributions in 5.0 (if I have not forgotten something) and then we can 
> > just polish it all just before the release. There will be still some room 
> > to do the housekeeping like this after these patches lend. It is not like 
> > Accord will be in trunk on Monday and we release Tuesday ...
> >
> > 
> > From: Maxim Muzafarov 
> > Sent: Monday, July 31, 2023 23:05
> > 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.
> >
> >
> >
> >
> > Hello everyone,
> >
> >
> > It's been a long time since the last discussion about the import order
> > code style, so I want to give these changes a chance as all the major
> > JIRA issues have already landed on the release branch so we won't
> > affect anyone. I'd be happy to find any reviewers who are interested
> > in helping with the next steps :-) I've updated the changes to reflect
> > the latest checkstyle work, so here they are:
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-17925
> > https://github.com/apache/cassandra/pull/2108
> >
> >
> > The changes look scary at first glance, but they're actually quite
> > simple and in line with what we've discussed above. In short, we can
> > divide all the affected files into two parts: the update of the code
> > style configuration files (checkstyle + IDE configs), and the update
> > of all the sources to match the code style.
> >
> > In short:
> >
> > - "import order" hotkey will work regardless of which IDE you are using;
> > - updated checkstyle configuration, and IDEA, Eclipse, NetBeans
> > configurations have been updated;
> > - AvoidStarImport checkstyle rule applied as well;
> >
> > The import order we've agreed upon:
> >
> > java.*
> > [blank line]
> > javax.*
> > [blank line]
> > com.*
> > [blank line]
> > net.*
> > [blank line]
> > org.*
> > [blank line]
> > org.apache.cassandra.*
> > [blank line]
> > all other imports
> > [blank line]
> > static all other imports
> >
> > On Mon, 27 Feb 2023 at 13:26, Maxim Muzafarov  wrote:
> > >
> > > > I suppose it can be easy for the existing feature branches if they have 
> > > > a single commit. Don't we need to adjust each commit for multi-commit 
> > > > feature branches?
> > >
> > > It depends on how feature branches are maintained and developed, I
> > > guess. My thoughts here are that the IDE's hotkeys should just work to
> > > resolve any code-style issues that arise during rebase/maintenance.
> > > I'm not talking about enforcing all our code-style rules but giving
> > > developers good flexibility. The classes import order rule might be a
> > > good example here.
> > >
> > > On Wed, 22 Feb 2023 at 21:27, Jacek Lewandowski
> > >  wrote:
> > > >
> > > > I suppose it can be easy for the existing feature branches if they have 
> > > > a single commit. Don't we need to adjust each commit for multi-commit 
> > > > feature branches?
> > > >
> > > > śr., 22 lut 2023, 19:48 użytkownik Maxim Muzafarov  
> > > > napisał:
> > > >>
> > > >> Hello everyone,
> > > >>
> > > >> I have created an issue CASSANDRA-18277 that may help us move forward
> > > >> with code style changes. It only affects the way we store the IntelliJ
> > > >> code style configuration and has no effect on any current (or any)
> > > >> releases, so it should be safe to merge. So, once the issue is
> > > >> resolved, every developer th

Re: [DISCUSS] How we handle JDK support

2025-05-23 Thread Mick Semb Wever
   .



> For the rare edge case where we have to stop supporting something entirely
>> because it's incompatible with a JDK release (has this happened more than
>> the 1 time?) - I think a reasonable fallback is to just not backport new
>> JDK support and consider carrying forward the older JDK support until the
>> release w/the feature in it is EoL'ed. That'd allow us to continue to run
>> in-jvm upgrade dtests between the versions on the older JDK.
>>
>
>
> This.
> I think the idea of adding new major JDKs to release branches for a number
> of reasons, in theory at least.  …
>


I *like* the idea … :)