It looks like there is a potential solution to the indeterministic
bytebuffer:
https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemoryLayout.html
& https://archive.fosdem.org/2020/schedule/event/bytebuffers/
Thanks,
Vivekanand K.
On Fri, May 9, 2025, 8:59 PM Vivekan
Made some progress. After adding
throughout build.xml and compiling the 5.03 branch with openjdk 17.0.15
2025-04-15
OpenJDK Runtime Environment Temurin-17.0.15+6 (build 17.0.15+6) I got a
build Failed error at the same position in exception. Please see:
https://github.com/apache/cassandra/pull/415
We thought we had this figured out when we did the big bang switch to
ByteBuffers, then spent years finding subtle bugs that the tests
didn't.
Kind Regards,
Brandon
On Fri, May 9, 2025 at 3:24 PM Jon Haddad wrote:
>
> There’s a pretty simple solution here - breaking it up into several smaller
>
There’s a pretty simple solution here - breaking it up into several smaller
patches.
* Any changes should include tests that validate the checks are used
correctly.
* It should also alleviate any issues with code conflicts and rebasing as
the merges would happen slowly over time rather than all at
My thinking is most closely aligned with Blake and Benedict’s views here.For the specific refactor in question, I support adoption of the language feature for new code or to cut existing code over to the new syntax as changes are made to the respective areas of the codebase. But I don’t support a s
No one is treating the codebase like a house of cards that can’t be touched.
In this case I think the cost/risk of doing this change outweighs the potential
benefits the project might see from it. Josh counts ~2000 instances where we’re
casting objects so we’re talking about a not-insignificant
Agreed. This is a change that’s fine to include when editing related (and new) code, but doesn’t come close to warranting a wide scale change.On 9 May 2025, at 18:32, Blake Eggleston wrote:This seems like a cool feature that will be useful in future development work, but not something we should b
Why not?
Personally, I hate the idea of treating a codebase (any codebase) like a
house of cards that can't be touched. It never made sense to me to try to
bundle new features / bug fixes with improvements to code quality.
Making the code more reliable should be a goal in itself, rather than a
s
This seems like a cool feature that will be useful in future development work,
but not something we should be proactively refactoring the project to make use
of.
On Fri, May 9, 2025, at 10:18 AM, Vivekanand Koya wrote:
> I would say that https://openjdk.org/jeps/394 (instanceOf) aims to provide
I can also provide potential examples if you'd like.
Thanks,
Vivekanand K.
On Fri, May 9, 2025 at 10:18 AM Vivekanand Koya <13vivekk...@gmail.com>
wrote:
> I would say that https://openjdk.org/jeps/394 (instanceOf) aims to
> provide safer and less poisoning in the code by default. Instead of hav
I would say that https://openjdk.org/jeps/394 (instanceOf) aims to provide
safer and less poisoning in the code by default. Instead of having a
production server halt/impaired due to a RuntimeException, instead it is
verified at compile time. If a new language feature makes code more robust
and add
> I would like to refactor the codebase (Trunk 5+) to eliminate unsafe explicit
> casting with instanceOf.
We have a rich history of broad sweeping refactors dying on the rocks of the
community's aversion to instability and risk w/out a concrete outcome we're
trying to achieve. :)
All of which
Sounds great. I would like to refactor the codebase (Trunk 5+) to eliminate
unsafe explicit casting with instanceOf.
Thanks,
Vivekanand
On Fri, May 9, 2025, 5:19 AM Benedict Elliott Smith
wrote:
> Yep, that approach seems more than sufficient to me. No need for lots of
> ceremony, but good to k
Yep, that approach seems more than sufficient to me. No need for lots of
ceremony, but good to keep everyone in the decision loop.
> On 9 May 2025, at 13:10, Josh McKenzie wrote:
>
>> I think it doesn’t cost us much to briefly discuss new language features
>> before using them.
> I had that th
I think it doesn’t cost us much to briefly discuss new language features before
using them. Lambdas, Streams and var all have problems - and even with the
guidance we publish some are still misused.
The flow scoping improvement to instanceof seems obviously good though.
> On 9 May 2025, at 12:3
> I think it doesn’t cost us much to briefly discuss new language features
> before using them.
I had that thought as well but on balance my intuition was there were enough
new features that the volume of discussion to do that would be a poor
cost/benefit compared to the "lazy consensus, revert"
For new feature work on trunk, targeting the highest supported language level
featureset (jdk17 right now, jdk21 within the next couple of weeks) makes sense
to me. For bugfixing, targeting the oldest supported GA branch and the highest
language level that works there would allow maximum flexibi
Hello,
I want to understand the community's thoughts on using newer features (post
JDK11) in upcoming releases in Cassandra. An example is flow scoping
instead of explicitly casting types with instanceOf:
https://openjdk.org/jeps/395. I want your thoughts on JDK requirements for
the main Cassandra
18 matches
Mail list logo
