JDK-8170591 : Modification of single java file in javafx.web causes recompilation of all other files
  • Type: Bug
  • Component: javafx
  • Sub-Component: build
  • Affected Version: 9
  • Priority: P4
  • Status: In Progress
  • Resolution: Unresolved
  • Submitted: 2016-12-01
  • Updated: 2019-07-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Blocks :  
Blocks :  
Relates :  
Relates :  
Relates :  
1. Change any java file related to WebKit (e.g. modules/javafx.web/src/main/java/com/sun/webkit/network/URLLoader.java)
2. Compile javafx with webkit (gradle -PCOMPILE_WEBKIT=true) and look at the timestamp of generated class(ls -l `find modules/javafx.web/build/classes/main/javafx.web -name *.class`) and JNI header files (ls -lh modules/javafx.web/build/gensrc/headers/javafx.web)
As regression labeled and introduced in 8u or 9 -- targeted to 10

Hashes won't be stored in a separate file, it will be computed on the-fly and if hashes are equal copy will be ignored, otherwise it will be copied into the destination.

Conceptually, this seems fine. I presume your plan is to store the hashes of each file, and copy each file that has a different (or missing) hash?

Instead of using "javah", I'm planning to generate JNI headers in a $buildDir/tmp directory and move it to $buildDir/gensrc/headers only if there is a content change(using sha1/md5). [~kcr], do you see any problem with this approach?

I have already created a bug JDK-8170585 to avoid including a header file in GraphicsContext.h which causes recompilation of native WebCore files(~340 files). Fixing JDK-8170585 will significantly reduce the number of files(to ~30) being compiled due to "javac -h" bug. As you mentioned, I will submit a fix to use "javah" for javafx until langtool fixes "javac -h".

Yes, this does look like a langtools bug. Regarding the incremental compilation of java files, this has been a known issue for several months (ever since we started using gradle 2 and now gradle 3), but you are right that it isn't relevant to your problem. We should file a separate bug for the langtools team to look at. In the mean time, we might need to go back to using javah explicitly.

Incremental build in gradle is an experimental feature[1] and it is even integrated with javafx using INCREMENTAL property. I tried with -PINCREMENTAL=true also, but no improvements. I tried with a revision which doesn't have changes from JDK-8161704(before switching to javac -h), though it compiles all java files, it doesn't compile lots of unrelevant native files. Finally I decided to check the difference between "javah" and "javac -h" using a simple code, echo "class Foo {native void foo();}" > Foo.java && javac Foo.java -h . && javah -o Foo_javah.h Foo && ls -lh Foo.class Foo.h Foo_javah.h -rw-r--r-- 1 ARAJKUMA wheel 200B Dec 2 17:12 Foo.class -rw-r--r-- 1 ARAJKUMA wheel 338B Dec 2 17:12 Foo.h -rw-r--r-- 1 ARAJKUMA wheel 338B Dec 2 17:04 Foo_javah.h (Tried multiple times) By looking at the timestamps "javac -h" generates new header file everytime we compile a source file, but "javah" intellegently avoids generating the header(even class file timestamp is new). Looks like a langtool bug!! [1] https://docs.gradle.org/current/dsl/org.gradle.api.tasks.compile.CompileOptions.html#org.gradle.api.tasks.compile.CompileOptions:incremental

Issue is not just associated with web module, but happens on all other module as well. Problem seems to be with the gradle itself[1]. I need to try gradle incremental build option. [1] http://stackoverflow.com/a/21561884/1942688

The same think will also happen if you change the JDK and rebuild, since it will recompile the java files. I noticed this last night when doing a test build -- all of WebKit was compiled twice during my sanity test build.

I noticed something like this, but hadn't realized it was compiling every file. I think I know why this is happening.

Looks like the problem started after JDK-8161704