RFR: 8054717: SJavac should track changes in the public apis of classpath classes!

[Magnus Ihse Bursie]

On 2015-03-03 15:03, Erik Joelsson wrote:
>
> On 2015-03-03 13:53, Magnus Ihse Bursie wrote:
>> On 2015-03-03 12:53, Erik Joelsson wrote:
>>> That combination didn't actually build for me. When compiling 
>>> jdk.jconsole, the following happened:
>>>
>>> java.lang.RuntimeException: 
>>> com.sun.tools.javac.code.Symbol$CompletionFailure: class file for 
>>> java.awt.datatransfer.UnsupportedFlavorException not found
>>>     at 
>>> com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:143)
>>>     at 
>>> com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:92)
>>>     at 
>>> com.sun.tools.sjavac.comp.SjavacImpl.compile(SjavacImpl.java:129)
>>>     at 
>>> com.sun.tools.sjavac.comp.PooledSjavac.lambda$compile$65(PooledSjavac.java:80)
>>>     at 
>>> com.sun.tools.sjavac.comp.PooledSjavac$$Lambda$4/703614162.call(Unknown 
>>> Source)
>>>     at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>     at 
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>>     at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>>     at java.lang.Thread.run(Thread.java:744)
>>> Caused by: com.sun.tools.javac.code.Symbol$CompletionFailure: class 
>>> file for java.awt.datatransfer.UnsupportedFlavorException not found
>>>
>>> From what I can tell, jdk.jconsole uses java.desktop, which uses 
>>> java.datatransfer (and re-exports it), where the missing class is. 
>>> My best guess is that something in sjavac (API checking?) needs to 
>>> traverse down into the transitive dependencies. This might be wrong, 
>>> but as a workaround, it's easiest to fix in the makefiles so that we 
>>> can have a working sjavac enabled jdk build.
>>>
>>> Here is an updated webrev which adds 3 levels (should cover 
>>> everything I think) of transitive dependencies on the classpath when 
>>> compiling modules:
>>>
>>> http://cr.openjdk.java.net/~erikj/8054717/webrev.root.02/
>>
>> I'm not quite following this. This change affects the dependency 
>> calculation even when not using sjavac, right? Will that not cause 
>> any issues? What is the reasoning with the 3 levels? Is that the 
>> maximum depth currently in the JDK?
>>
> I changed this to only affect SJAVAC_ENABLED builds. The 
> implementation of FindTransitiveDependenciesForModule was taken from 
> another branch where I had already needed it for a different reason. 
> There, 3 levels happened to be enough and applying this patch solved 
> the problem with sjavac, so I took it as it was for now.
>> Also, a minor nit, I thought we'd agreed to get rid of the $BUILD/tmp 
>> directory, and store intermediate build stuff in support or 
>> make-support.
>>
> Right, I moved it to support.
>
> New webrev: http://cr.openjdk.java.net/~erikj/8054717/webrev.root.03/
Thanks. I'm happy now! :-)

/Magnus