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

Mandy Chung mandy.chung at oracle.com
Tue Jul 8 17:45:09 UTC 2014


On 7/8/14 9:43 AM, Joe Darcy wrote:
> 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.
>

Agree it's kind of a stretch.  This is an interim solution to help 
transition to modules that may be ok to live it?

Mandy

> 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