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
