On 11/09/2013 03:50, David M. Lloyd wrote:
I'm aware of that; however I guarantee you that if you try to munge
this functionality up with the concept of exported classes or packages
before the module system is realized, it's going to end up wrong and
we'll have yet more dead cruft in the API.
There isn't any real functionality here, it's simply an effort to make
it clear which com.sun.** APIs are okay for developers to depend on.
This is useful for JDK maintainers too.
If/when we move to a modular JDK then it would be reasonable to expect
that the @Exported APIs would be APIs that applications can continue to
depend on. It may be that some of the non-@Exported JDK-specific APIs
are completely hidden from applications, in which case having @Exported
now is a good thing as it helps developers and tooling be aware that
they may be directly using JDK internal APIs, perhaps unknowingly. We
also include rudimentary tooling (jdeps) to help in the effort to
understand dependencies. It may be that jdeps should be extended to also
look at the @Exported annotation.
As I mention non-@Exported APIs then I don't think (and Joe can confirm)
that there is any intention to add @Exported(false) to thousands of
JDK-internal classes (and their package-info.java if it exists). Rather,
if @Exported is not present then the default answer has to be that it is
ambiguous and so not safe to depend on. Assuming I have this right then
it means that @jdk.Exported (or whatever the final name is) will only be
added to the small number of JDK-specific APIs that are long term
stable/supported/documented APIs. This is consistent with the patches
that have been discussed to date [1][2].
-Alan
[1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/011cf7e0a148
[2]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014691.html
