NullAway's rules for fields require that all non-null fields be initialized before a constructor completes. The modularity model that NullAway is using here differs from the one that Specimin currently implements (based on the Checker Framework's typechecking rules) in the following ways:
all nonnull fields in a class can impact whether a warning is issued in a constructor, and so should be preserved. This is because the absence of an assignment to a field can trigger a warning.
the bodies of private or final methods that are directly called at the top level by a constructor can impact whether NullAway issues a warning in the constructor, because NullAway permits methods with those restrictions to also assign nonnull fields (to prevent the error above)
I think this means we need to introduce a separate modularity model for NullAway that reflects these differences.
This is the reason that Specimin currently does not preserve na-323, even with the change in #331.
NullAway's rules for fields require that all non-null fields be initialized before a constructor completes. The modularity model that NullAway is using here differs from the one that Specimin currently implements (based on the Checker Framework's typechecking rules) in the following ways:
all nonnull fields in a class can impact whether a warning is issued in a constructor, and so should be preserved. This is because the absence of an assignment to a field can trigger a warning.private
orfinal
methods that are directly called at the top level by a constructor can impact whether NullAway issues a warning in the constructor, because NullAway permits methods with those restrictions to also assign nonnull fields (to prevent the error above)I think this means we need to introduce a separate modularity model for NullAway that reflects these differences.
This is the reason that Specimin currently does not preserve na-323, even with the change in #331.