JDK-8232379 : Need to remove large icudt64l.zip binary file from source repository
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u241,openjfx11,openjfx14
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-10-16
  • Updated: 2021-09-03
  • Resolved: 2021-04-09
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.
JDK 8 Other
8u301Fixed openjfx11.0.12Fixed
Related Reports
Blocks :  
JDK-8260245 - Update ICU4C to version 68.2
Relates :  
JDK-8218640 - Update ICU4C to version 64.2
Relates :  
JDK-8178360 - Build and integrate ICU from source
Description
We need to remove the following large binary file from the repo and instead host and download it from a server:

modules/javafx.web/src/main/native/Source/ThirdParty/icu/java/data/icudt64l.zip

The file is 11 Mbytes, which is excessively large to store in a source code repository. It is updated infrequently, when ICU library is updated, as was recently done in JDK-8218640.
Comments
Changeset: 808b1078 Author: Arun Joseph <ajoseph@openjdk.org> Date: 2021-04-09 07:07:38 +0000 URL: https://git.openjdk.java.net/jfx/commit/808b1078
09-04-2021
This comment records a discussion we had offline on this. We have two alternatives, and I wanted to list them both along with the pros / cons so we can decide how to proceed. 1. Generate the icudt file the same way we do now, as part of the ICU update, but rather than checking it into the jfx repo, upload it to a binary repository. We would checkin the version information to identify the icudt along with instructions for how to generate it. The icudt file would be downloaded at build time along with other build dependencies. This is the plan of record. 2. Check in the sources and Makefiles for generating the icudt file into the jfx repo, and build icudt each time ICU is built, meaning when using "-PCOMPILE_WEBKIT=true". Option 1 is easier since we would use our existing procedure to build icudt as part of an ICU upgrade, and then create a zip file from it. We would then upload the icudt zip file to maven central instead of committing it to the repo. There would be some initial work to change the build to download it like we do for other dependencies, but that would be easy. We would also as part of this, document the instructions for creating this dat file and commit those instructions into the repo (which is a good idea anyway), and also add information to the repo to identify the tag from which it was built. The only drawback of this approach is that we have a binary data file that we ship that is stored somewhere other than the repo (although a "pointer" would be stored in the repo). Option 2 is initially more work, since we would have to take what is currently a one-time manual build step and check in the sources and Makefiles to build it from the JavaFX SDK build. The WebKit build system is CMake based and the icudt files use regular Makefiles. We would either have to call one from the other, or have a separate step where build gradle calls the ICU Makefiles directly from gradle before calling cmake. In addition to the one-time complexity, we would need to commit the entire ICU data sources into our repo, and pay the cost of building icudt for each build even though we only ever change it when we update ICU, roughly once every 18-24 months. The big advantage of this is that it is more in keeping with our best practices of building everything from source; worth noting in this case is that it is a static data file, so not the same as downloading binary code, which really is a bad idea, and which we used to do prior to JDK-8178360. If feasible, we prefer option #2. We plan to prototype that option to see how much work it's likely to be, and how much it will increase the build time of a WebKit build. After prototyping it we can evaluate it and decide which way to go.
25-02-2021
This isn't critical for openjfx14, so moving to openjfx15. The only hard deadline is that we need to do this before we update the ICU library again, which will be beyond the end of life for FX 14.
29-01-2020