jdeps - option to to analyze package-private API

[Alan Bateman]

On 03/12/2022 18:15, Matej Turcel wrote:
> :
>
> So far, jdeps with the --api-only flag seems like the perfect tool, 
> except
> there is a little problem -- we have packages (dozens of them) which
> exist in multiple modules. For example, package `com.foo` exists in
> three separate modules (meaning each of these modules has a class in that
> package). That means package-private "stuff" (members + 
> constructor/method
> signatures) is a part of module's API. So to infer correct types of 
> gradle
> module dependencies using jdeps, we need jdeps to consider 
> package-private
> stuff a part of the API.

The scenario seems a bit unusual in that API elements with package 
access aren't usually considered to be part of the API. Does the javadoc 
published for users of these components include the API elements with 
package access?  I realize Gradle may define "module" to mean something 
else but for the Java platform, a module is a set of packages.

I haven't seen any opinions from others but my initial reaction is that 
it wouldn't be a good idea to change --api-only to consider API elements 
with package access to be part of the API. If jdeps were changed then it 
would need a new option.


>
> On an unrelated note, I believe bounds of type parameters should be
> a part of type's API:
>
>     public class C<T extends Boolean> {
>         T x;
>     }
>
> But according to jdeps they are not:
>
>     > jdeps --verbose C.class
>     C.class -> java.base
>        C       -> java.lang.Boolean        java.base
>        C       -> java.lang.Object         java.base
>
>     > jdeps --verbose --api-only C.class
>     C.class -> java.base
>        C       -> java.lang.Object         java.base
>
> Is this behavior intended?
>
jdeps could read the Signature attribute but I think it would complicate 
the output to try to have it include the bounds.

-Alan