8332085: Remove 10 year old transition check in GenerateCurrencyData tool

[naotoj]

Fixing a build error on 8u-RI. The build tool that generates the currency data had a check that throws an exception if the transition date is more than 10 years away (past/future). The check does not seem meaningful. Removing the check will fix the issue.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• JDK-8332085 needs maintainer approval
• Commit message must refer to an issue

Issue

• JDK-8332085: Remove 10 year old transition check in GenerateCurrencyData tool (Bug - P4 - Approved)

Reviewers

• Justin Lu (@justin-curtis-lu - no project role)
• Iris Clark (@irisclark - Author)
• Lance Andersen (@LanceAndersen - Reviewer)
• Phil Race (@prrace - Reviewer)
• Erik Joelsson (@erikj79 - Reviewer)
• Andrew John Hughes (@gnu-andrew - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-ri.git pull/17/head:pull/17
$ git checkout pull/17

Update a local copy of the PR:
$ git checkout pull/17
$ git pull https://git.openjdk.org/jdk8u-ri.git pull/17/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 17

View PR using the GUI difftool:
$ git pr show -t 17

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk8u-ri/pull/17.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back naoto! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@naotoj This change now passes all automated pre-integration checks.

After integration, the commit message for the final commit will be:

8332085: Remove 10 year old transition check in GenerateCurrencyData tool

Reviewed-by: jlu, iris, lancea, prr, erikj, andrew

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been no new commits pushed to the master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[justin-curtis-lu]

LGTM

[openjdk]

⚠️ @naotoj This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[mlbridge]

Webrevs

• 00: Full (735e392c)

[prrace]

Assuming a currency is no longer trustworthy because (and only because) 10 years has passed is a heuristic I suppose, but a dubious one, and a refusal to build seems a questionable way to inform people.

[naotoj]

Assuming a currency is no longer trustworthy because (and only because) 10 years has passed is a heuristic I suppose, but a dubious one, and a refusal to build seems a questionable way to inform people.

It only affects the entry with transition date, such as currency code switching XXX to XXY on that date, and the transition date is stale in this case, so currency code itself is supposed to be correct. Yet there is no convincing reasoning for the 10 year boundary.

[gnu-andrew]

The check has existed since OpenJDK's inception and still exists in trunk, so I can't find a reason as to why it was added. My presumption would be to enforce cleaning up the file regularly, but this seems to be happening anyway. JDK-8193552 removed the problematic Latvia & Lithuania values causing the current trouble in 2018 and JDK-8321480 just removed the Croatian one nine years before this check kicks in.

I'd be in favour of getting rid of the check if you also wanted to take this change to trunk, where it still exists. It seems likely the check will cause more trouble than the problem it is trying to solve. Having the "special case" currency values (all three values make it to the JDK data file and the choice is made at runtime) does mean having to do a date comparison that is avoidable, but I think a warning would suffice rather than breaking the build.

This is a good example of how such changes can take time to trickle down to all releases (if they ever do). I still remember being hit by this in 2014 with TR=TRL;2004-12-31-22-00-00;TRY still being present in some old releases. JDK-
7077119 removed some very old ones not long before they hit the ten year mark.

I think this is the best approach for the reference implementation, without altering the data at all.

[gnu-andrew]

/approve yes

[openjdk]

@gnu-andrew
8332085: The approval request has been approved.

[naotoj]

/integrate
Thanks, @gnu-andrew. Yes, fixing it in the mainline (and its further backports) is planned.

[openjdk]

Going to push as commit 4f3b76f.

[openjdk]

@naotoj Pushed as commit 4f3b76f.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.