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 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 addresses a hazardous, historical design choice, I believe it's time > has arrived. Curious to see what everyone thinks. > > Thanks, > Vivekanand K. > > On Fri, May 9, 2025 at 9:51 AM Josh McKenzie <jmcken...@apache.org> wrote: > >> 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 is to say: do we have examples of instanceOf casting blowing >> things up for users that would warrant going through the codebase to tidy >> this up? Between src/java and test/unit and test/distributed we have around >> 2,000 occurrences of this pattern. >> >> On Fri, May 9, 2025, at 10:14 AM, Vivekanand Koya wrote: >> >> 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 <bened...@apache.org> >> wrote: >> >> 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 <jmcken...@apache.org> wrote: >> >> 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" approach. >> >> So if I actually do the work required to have an opinion ;): >> >> https://docs.oracle.com/en/java/javase/21/language/java-language-changes-release.html#GUID-6459681C-6881-45D8-B0DB-395D1BD6DB9B >> >> JDK21: >> - Record Patterns >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-7623D3AD-4141-4914-A384-60C65BD0C010> >> - Pattern Matching for switch Expressions and Statements >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-E69EEA63-E204-41B4-AA7F-D58B26A3B232> >> - String Templates >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-78F545D3-CDD0-415C-9B4B-6EF361D184F5> >> - Unnamed Patterns and Variables >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-D54E1CF1-BDFD-4B57-8A6E-5B4C87F4D58A> >> - Unnamed Classes and Instance Main Methods >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase21&id=GUID-35544A22-61AB-4928-99BB-A9DD1CA062FF> >> JDK17: >> - Sealed Classes >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase17&id=GUID-0C709461-CC33-419A-82BF-61461336E65F> >> JDK16: >> - Pattern Matching for instanceof >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase16&id=GUID-843060B5-240C-4F47-A7B0-95C42E5B08A7> >> JDK15: >> - Text Blocks >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase15&id=GUID-221D06A2-FF54-4DB3-A6DA-179B8F76DB05> >> JDK14: >> - Switch Expressions >> <https://docs.oracle.com/pls/topic/lookup?ctx=javase14&id=GUID-BA4F63E3-4823-43C6-A5F3-BAA4A2EF3ADC> >> JDK11: >> - Local Variable Type Inference >> <https://docs.oracle.com/en/java/javase/21/language/local-variable-type-inference.html#GUID-D2C58FE6-1065-4B50-9326-57DD8EC358AC> >> (test >> only, not prod code is where we landed) >> >> Assuming we just lazily evaluate and deal with new features as people* >> actually care about them* and seeing them add value, a simple "[DISCUSS] >> I'm thinking about using new language feature X; any objection?" lazy >> consensus that we then dumped onto a wiki article / code style page as >> "stuff we're good to use" would probably be fine? >> >> >> On Fri, May 9, 2025, at 7:58 AM, Benedict wrote: >> >> >> 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:30, Josh McKenzie <jmcken...@apache.org> wrote: >> >> >> 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 >> flexibility with minimal re-implementation. >> >> If anyone has any misgivings with certain features (i.e. the debate >> around usage of "var") they can bring it up on the dev ML and we can >> adjust, but otherwise I'd prefer to see us have more modern evolving >> options on how contributors engage rather than less. >> >> On Fri, May 9, 2025, at 1:56 AM, Vivekanand Koya wrote: >> >> 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 repository, Accord, and Sidecar. >> >> Much appreciated. >> Thanks, >> Vivekanand K. >> >> >> >> >>
