<div style="font-family: Arial, sans-serif; font-size: 14px;">I somewhat feel like these side car static type analysers fail to catch on in Java because annotations are too flexible and thus poorly suited for catching type information. In comparison with python where there are many tools but there may only be a single type annotation, in Java there are many tools with multiple overlapping type annotations that can each be redundantly applied while there is only a single language level type ascribed that doesn't support restrictions without OOP ceremony. If there was a dedicated unique additional type annotation maybe tools would attempt to be more interoperable with one another but also maybe not.</div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;">Today we have tools like Checker competing with JSpecify and the tools that came before it, and JSpecify even pointing at the sad state of affairs in a stackoverflow question (on the level of null restriction) where there are many competing and poorly interoperating tools. When the interoperability story is complex, the choice is hard to make and living with the lack of restrictions seems ok (alternately one can make between simply guarding like usual or going with the OOP ceremony).</div><div style="font-family: Arial, sans-serif; font-size: 14px;" class="protonmail_signature_block protonmail_signature_block-empty">
    <div class="protonmail_signature_block-user protonmail_signature_block-empty">
        
            </div>
    
            <div class="protonmail_signature_block-proton protonmail_signature_block-empty">
        
            </div>
</div>
<div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div class="protonmail_quote">
        On Thursday, October 16th, 2025 at 2:12 AM, Archie Cobbs <archie.cobbs@gmail.com> wrote:<br>
        <blockquote class="protonmail_quote" type="cite">
            <div dir="ltr"><div dir="ltr">On Wed, Oct 15, 2025 at 11:34 AM Manu Sridharan <<a href="mailto:manu@sridharan.net" rel="noreferrer nofollow noopener">manu@sridharan.net</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr">This is all mostly possible via the Checker Framework and similar approaches. </div></div></blockquote><div><br></div><div>In the spirit of due diligence, I am attempting to implement something like "WHAT I WANT" using the checker framework. Currently I'm battling a poor progress/confusion ratio.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr">You wouldn’t need <code style="border:1px solid rgb(206,206,206);background-color:rgb(248,248,248);padding:0px 3px;border-radius:4px">@SuppressWarnings</code> annotations for validation either, due to <a href="https://checkerframework.org/manual/#type-refinement" target="_blank" rel="noreferrer nofollow noopener">type refinement</a>.  And, for this type of property, where you’re essentially trying to introduce new subtypes of an existing type and then enforce type compatibility at assignments, the implementation effort to write the checker is pretty low.</div></div></blockquote><div><br></div><div>Let me know offline if you (or anyone else) is interested in helping me prototype something (I have a primordial github project).</div><div><br></div><div>Thanks,</div><div>-Archie</div><div> </div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>

        </blockquote><br>
    </div>