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/
/Erik
On 2015-03-03 12:17, Erik Joelsson wrote:
Hello,
Here is my suggestion for makefile changes to go with the sjavac
changes. Adding build-dev to get review for my part.
Webrev: http://cr.openjdk.java.net/~erikj/8054717/webrev.root.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8054717
/Erik
On 2015-03-02 13:31, Andreas Lundblad wrote:
On Mon, Mar 02, 2015 at 09:42:58AM +0100, Erik Joelsson wrote:
Sounds good to me. So you think I should do the makefile changes to
adapt the JDK build to this patch in a separate bug?
I'm not sure what's best, but I don't think we need a separate
bug-entry.
If you give me a pointer (or patch) on how to create/clean up a dummy
empty bootclasspath directory, I can do the push.
-- Andreas
