@Supported design issues

[Alan Bateman]

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- at 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- at 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