You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This feature is requested by the community as reflective calls are often concentrated within a single package where fine-grained reflection metadata gives little benefit in terms of image size, but requires a lot of additional work for the users.
The proposed extension would allow to include a * wildcard to the type in reachability-metadata.json. The * wildcard would register all types from a single package for reflection. For example, my.pkg.* will add classes from package my.pkg but not from my.pkg.nextlvl.
The wildcards would be allowed only directly after the . and as the last character in the sequence. Patterns like my.pkg.Message* or my.pkg.*Message would not be allowed.
The wildcard pattern would not allow access to individual fields or methods, but it would only allow for the bulk inclusion. The following fileds would be considered in the wildcard syntax:
Concern: Libraries could pull in extra classes from other libraries on the classpath. The libraries are still constrained to the single package so it would likely not include much of the classpath. Patterns like my.pkg.** would not be allowed to prevent accidental inclusion of extra classes.
Discussed:
Should we allow ** for recursive package inclusion?
This can be very dangerous. A library can significantly increase image size for all users by using overly broad include patterns (e.g., org.apache.** and similar). The reasoning is that there typically not so many packages in a project to allow this kind of expressiveness.
Should we allow wildcards in the middle of the string?
This can be confusing, people. If practice shows that this is necessary, we can always add this feature.
Open Questions:
Should we allow methods and fields to be included into the wildcard pattern?
This would make this feature more sophisticated resembling a query engine making it hard to understand, but it would also make the semantics of reachability-metadata.json more regular.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This feature is requested by the community as reflective calls are often concentrated within a single package where fine-grained reflection metadata gives little benefit in terms of image size, but requires a lot of additional work for the users.
The proposed extension would allow to include a
*
wildcard to thetype
inreachability-metadata.json
. The*
wildcard would register all types from a single package for reflection. For example,my.pkg.*
will add classes from packagemy.pkg
but not frommy.pkg.nextlvl
.The wildcards would be allowed only directly after the
.
and as the last character in the sequence. Patterns likemy.pkg.Message*
ormy.pkg.*Message
would not be allowed.The wildcard pattern would not allow access to individual fields or methods, but it would only allow for the bulk inclusion. The following fileds would be considered in the wildcard syntax:
Concern: Libraries could pull in extra classes from other libraries on the classpath. The libraries are still constrained to the single package so it would likely not include much of the classpath. Patterns like
my.pkg.**
would not be allowed to prevent accidental inclusion of extra classes.Discussed:
Should we allow
**
for recursive package inclusion?This can be very dangerous. A library can significantly increase image size for all users by using overly broad include patterns (e.g.,
org.apache.**
and similar). The reasoning is that there typically not so many packages in a project to allow this kind of expressiveness.Should we allow wildcards in the middle of the string?
This can be confusing, people. If practice shows that this is necessary, we can always add this feature.
Open Questions:
Should we allow
methods
andfields
to be included into the wildcard pattern?This would make this feature more sophisticated resembling a query engine making it hard to understand, but it would also make the semantics of
reachability-metadata.json
more regular.Beta Was this translation helpful? Give feedback.
All reactions