Paul King created GROOVY-12207:
----------------------------------
Summary: Consult package-info.class of dependencies during
resolution
Key: GROOVY-12207
URL: https://issues.apache.org/jira/browse/GROOVY-12207
Project: Groovy
Issue Type: Improvement
Reporter: Paul King
Groovy's resolver does not consult {{package-info.class}} for the packages of
precompiled dependencies, so package-level annotations of libraries are
invisible to the compiler and to type-checking extensions.
JSpecify's {{@NullMarked}} is commonly applied at package level (and may also
be applied at module level), meaning an entire library's nullness defaults are
typically expressed in files Groovy never reads. Without this, per-element type
annotations (see the companion type-annotation ingestion issue) tell only half
the story: a {{@NullMarked}} package with unannotated method signatures means
"everything here is non-null", and Groovy would wrongly treat it as unspecified.
Proposed scope:
# On-demand loading of {{package-info.class}} for the package of a resolved
class, with caching (including negative caching for packages without one),
reusing the existing decompiled-class infrastructure.
# Expose the package annotations via a suitable API (e.g. on {{PackageNode}} or
a resolver service) so checkers and AST transforms can query them for
dependency packages the way they already can for source packages.
# Consider {{module-info}} annotations ({{@NullMarked}} at module level) as a
stretch goal.
Behaviour-neutral on its own: this only makes existing metadata reachable.
Consumers include the incubating {{groovy.typecheckers.NullChecker}} (which
already recognizes {{@NullMarked}}/{{@NullUnmarked}} by name but can currently
only see them on classes in the compilation unit).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
