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

[Erik Joelsson]

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/

/Erik