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

[Magnus Ihse Bursie]

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?

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.

/Magnus