[
https://issues.apache.org/jira/browse/GROOVY-12207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-12207:
-------------------------------
Description:
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.
# Extend {{NullChecker}} to know about this new annotation information.
# 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).
was:
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).
> 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
> Priority: Major
>
> 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.
> # Extend {{NullChecker}} to know about this new annotation information.
> # 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)
