Ad hoc type restriction
Aaryn Tonita
atonita at proton.me
Thu Oct 16 08:41:18 UTC 2025
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.
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).
On Thursday, October 16th, 2025 at 2:12 AM, Archie Cobbs <archie.cobbs at gmail.com> wrote:
> On Wed, Oct 15, 2025 at 11:34 AM Manu Sridharan <manu at sridharan.net> wrote:
>
>> This is all mostly possible via the Checker Framework and similar approaches.
>
> 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.
>
>> You wouldn’t need @SuppressWarnings annotations for validation either, due to [type refinement](https://checkerframework.org/manual/#type-refinement). 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.
>
> Let me know offline if you (or anyone else) is interested in helping me prototype something (I have a primordial github project).
>
> Thanks,
> -Archie
> --
>
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20251016/751db8d7/attachment-0001.htm>
More information about the amber-dev
mailing list