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: 2024-11-21
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.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8172236 - Improve gradle incremental build performance
Blocks :  
JDK-8170730 - javac always generates JNI header regardless of source change
Blocks :  
JDK-8344728 - ☂ Gradle build modernization
Relates :  
JDK-8161704 - Switch to Jigsaw-aware boot JDK for compiling FX 9
Relates :  
JDK-8170585 - Fix PlatformContextJava type leaking to GraphicsContext
Relates :  
JDK-8192806 - Building javafx.web module still requires javah
Description
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)
Comments
As regression labeled and introduced in 8u or 9 -- targeted to 10
17-02-2017
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.
16-12-2016
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?
15-12-2016
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?
15-12-2016
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".
02-12-2016
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.
02-12-2016
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
02-12-2016
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
02-12-2016
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.
01-12-2016
I noticed something like this, but hadn't realized it was compiling every file. I think I know why this is happening.
01-12-2016
Looks like the problem started after JDK-8161704
01-12-2016