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
Context: #1097 (comment)
Context: #1097 (comment)
Context: b274a67
During code review, two questions came to light:
1. Will this cause API breakage in AndroidX/etc., because
`module-info.class` will make types "disappear"?
(See also b274a67).
2. `class-parse` can accept *multiple* `.jar` files and `.class`
files on the command-line. Should `module-info.class` processing
apply to *everything*?
Address the first concern by keeping `//*/@visibility` as `public`,
and instead if we think the type should be "internal" we instead add
an `//*/@annotated-visibility` attribute value of `module-info`.
If there is *already* an `//*/@annotated-visibility` value, then we
*append* ` module-info` to the attribute value.
Address the second concern by re-working `class-parse` command-line
parsing. There is now a "global `ClassPath`", which will be used
to hold `.class` files provided on the command-line. `.jar` and
`.jmod` files provided on the command-line will be given their own
`ClassPath` instances, and `module-info.class`-based visibility
fixups are specific to each `ClassPath` instance. Global files are
processed together. There is thus no way for `module-info.class`
visibility changes from `a.jar` to impact `b.jar`. After
visibilities are fixed up, we then merge everything into the "global"
`ClassPath` instance before writing transforming to XML.
Additionally, `class-parse --dump` can now accept `.jar` files,
and will dump out *all* `.class` filers within the `.jar` file.
To make this output easier, each "entry" starts with a "header" of
`-- Begin {ClassFile.FullJniName}`, and a blank link will be printed
between each entry.
0 commit comments