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