Review request: 8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API (original) (raw)

Joe Darcy joe.darcy at oracle.com
Tue Jul 8 16:43:01 UTC 2014

A note on the intended use of jdk.Exported; that annotation is intended for use on JDK-specific classes and not on classes that are part of a Java SE API:

 "This annotation should only be applied to types and packages

/outside/ of the Java SE namespaces of |java.| and |javax.| packages." http://docs.oracle.com/javase/jp/8/jdk/api/javac/tree/jdk/Exported.html

So while javax.jnlp is not part of the Java SE platform API, I think it is a stretch to apply jdk.Exported to it.

Cheers,

-Joe

On 07/08/2014 07:59 AM, Mandy Chung wrote:

I took out the special case for javax.jnlp and follow up the change in deploy to use @jdk.Exported to indicate its supportedness. I also added a new test case to check the dot file output: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.01

thanks Mandy On 6/25/14 1:21 PM, Mandy Chung wrote: This patch is also intended to target for 8u40 backport. It fixes the following issues:

JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API JDK-8039007 jdeps incorrectly reports javax.jnlp as JDK internal APIs JDK-8031092 jdeps does not recognize --help option. JDK-8048063 (jdeps) Add filtering capability Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.00/ jdeps will determine if it's a JDK internal API by checking the @jdk.Exported. It also reads tools.jar and flags if they are non-exported. javax.jnlp is supported API but not annotated with @jdk.Exported and so we special case it as a workaround. A new -filter option is added to provide an easy way to do filtering e.g. -filter java.lang.*, -filter:archive to filter out all dependences from the same archive (i.e the input JAR file or directory). The default is changed to filter out the dependences within the same package. I also have cleaned up and refactored some code between JdepsTask and Analyzer to prepare for source restructuring and modularization work. thanks Mandy

More information about the core-libs-dev mailing list