JDeps: detecting offending packages

Mandy Chung mandy.chung at oracle.com
Sat Nov 14 16:05:25 UTC 2015


> On Nov 14, 2015, at 7:20 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 13/11/2015 21:58, Robert Scholte wrote:
>> :
>> 
>> Previous versions of JDK9 gave me the following output:
>> 
>> classes -> java.base
>>   <unnamed> (classes)
>>      -> java.io
>>      -> java.lang
>>      -> sun.misc                                           JDK internal API (java.base)
>> 
>> 
>> The current b86 gives me:
>> 
>> classes -> java.base
>>   <unnamed> (classes)
>>      -> java.io
>>      -> java.lang
>>      -> sun.misc
>> 
>> So why this change? And is there another way to detect the usage of non-accessible classes?
>> 
>> The maven-plugin has a parameter called failOnWarning (default:true) which should break the build in order to help developers to change their code when they rely on internal classes.
> 
> In the regular JDK 9 EA builds then a usage of sun.misc.BASE64Decoder will be reported as a usage of a JDK internal API.
> 
> Not so with the Jigsaw builds because package sun.misc is temporarily exported by module java.base. This means that all public types in that package are accessible. This might seem surprising but it is because we're not there yet with JEP 260 [1]. Once JEP 260 is further along thne the critical internal APIs listed in JEP 260 will be accessible. The non-critical internal APIs will be encapsulated.

I think jdeps should continue to flag the critical JDK internal APIs listed in JEP 260 but they are accessible at runtime.  I file a bug:

https://bugs.openjdk.java.net/browse/JDK-8143011

> 
> For the Maven plugin then maybe it might be better to choose a JDK-internal type that is not in sun.misc or sun.reflect. That would keep your test stable while we work through all the transition issues.


Yes that allows to work through the transition.

Mandy



More information about the jigsaw-dev mailing list