jdeps - option to to analyze package-private API

Matej Turcel matej.turcel at oracle.com
Tue Dec 13 15:46:59 UTC 2022


On 12.12.2022 16:26, Alan Bateman wrote:
> The scenario seems a bit unusual in that API elements with package 
> access aren't usually considered to be part of the API.

Yes, they shouldn't be. But our code is not perfect and we have many 
cases where package-private elements de-facto are a part of the API.

> I realize Gradle may define "module" to mean something else but for 
> the Java platform, a module is a set of packages.

Gradle currently does not support specifying which packages are a part 
of the API, although according to the docs [1] this should be possible 
in a future release. However, doing so would require a massive effort on 
our side since we need to figure out which packages should be a part of 
the API and our codebase is quite large. But if we were to do this (and 
we may, as an intermediate step in our transition to jigsaw), the 
functionality I propose would be very helpful in doing so.

I may note that we only consider as API those packages, which are 
actually used from another module -- not everything package-private is 
automatically in the API.

[1] 
https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_recognizing_dependencies 


> 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.
Of course, that was my idea as well. FYI, I have already implemented 
this change, and I would like to make these changes directly in OpenJDK 
as well to avoid maintenance burden. For example, JDK-8294969 will break 
my changes, so I will have to rewrite them when we switch to newer JDK.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221213/f2924ba3/attachment-0001.htm>


More information about the core-libs-dev mailing list