Wildcards for reflection in reachability-metadata.json.

[vjovanov]

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:

{
  "type": "my.pkg.*"
  "allDeclaredConstructors": true,
  "allDeclaredMethods": true,
  "allDeclaredFields": true,
  "allPublicConstructors": true,
  "allPublicMethods": true,
  "allPublicFields": true,
  "serializable": true,
  "jniAccessible": true,
  "unsafeAllocated": true
}

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:

1. 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.

2. 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:

1. 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.

[zakkak]

Should we allow methods and fields to be included into the wildcard pattern?

IMHO no, it would indeed complicate things and sounds like a rare use case. "If practice shows that this is necessary, we can always" revisit :)