On Mon, 26 Feb 2024 14:20:40 GMT, Erik Joelsson <er...@openjdk.org> wrote:
>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The >> `COMPAT` locale data was introduced for applications' migratory purposes >> transitioning to `CLDR`. It is becoming a technical debt and now is the time >> to remove it (we've been emitting a warning at JVM startup since JDK21, if >> the app is using `COMPAT`). A corresponding CSR has also been drafted. > > make/modules/java.base/gensrc/GensrcLocaleData.gmk line 58: > >> 56: ifeq ($(MODULE), jdk.localedata) >> 57: $(shell $(RM) >> $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata/sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo_jdk_localedata.java) >> 58: endif > > The remainder of this file doesn't seem to be doing anything useful. Do we > really need to keep it around? If I understand this correctly, the files > referenced and deleted here are generated by the cldrconverter. Is that build > tool relying on make removing the file first? Reading the java source, my > impression is that it will generate the file unconditionally regardless of > the files current existence as long as the tool is run. Actually, as the file currently in the PR, it does not seem like it does anything at all, since we no longer create `_the.locale_resources`. Or... hm, without that file, `PREV_LOCALE_RESOURCES` will always be empty. I wonder what `$(filter-out $(PREV_LOCALE_RESOURCES), $(LOCALE_RESOURCES))` returns in that case. If it is empty, then this file does nothing. If it is `$(LOCALE_RESOURCES)`, then we will unconditionally rm the two files. I believe the original intention was to spot added or removed locale resources, and use that to trigger a re-generation. This does not seem to work at all anymore. Do we still need that kind of behavior? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1502955421
