thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James E. King, III (JIRA)" <>
Subject [jira] [Commented] (THRIFT-4530) proposal: add nullability annotations to generated Java code
Date Mon, 26 Mar 2018 15:08:00 GMT


James E. King, III commented on THRIFT-4530:

If nullable annotations have no other side-effects why don't we just add the annotation and
then at such time someone finds a need to disable it they can add the code necessary to do

> proposal: add nullability annotations to generated Java code
> ------------------------------------------------------------
>                 Key: THRIFT-4530
>                 URL:
>             Project: Thrift
>          Issue Type: New Feature
>          Components: Java - Compiler
>            Reporter: Manu Sridharan
>            Priority: Major
> I'd like to propose (optionally) including {{@Nullable}} annotations in Thrift-generated
Java code.  I'm the main author of NullAway ([] and we'd
like to better support users who are using Thrift.  The change would involve changing the
Java code generator to include {{@Nullable}} annotations on every field, method return value,
and method parameter in the public API of generated code that may be null.  With these annotations,
NullAway users will get warnings when their client code is missing appropriate null checks. 
Also, IDEs like IntelliJ will give better warnings about missing null checks.  As part of
this change, I would also add support to NullAway for understanding {{isSetX()}} methods to
avoid excessive false positives.
> Regarding which {{@Nullable}} annotation to use, Thrift seems to try to minimize third-party
dependencies, but we could simply include a new Thrift {{@Nullable}} annotation, and it will
work fine with NullAway and most other tools.
> I have a WIP patch to generate these annotations, but I wanted to get feedback from the
maintainers before opening a PR.  We could of course make the annotation generation optional
and default it to being off, if desired.  Anyway, thoughts / feedback welcome.  Thanks!

This message was sent by Atlassian JIRA

View raw message