-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8347949: Currency method to stream available Currencies #23165
8347949: Currency method to stream available Currencies #23165
Conversation
👋 Welcome back jlu! A progress list of the required criteria for merging this PR into |
@justin-curtis-lu This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
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 17 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
@justin-curtis-lu The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
// Initialize the set of available currencies if needed | ||
private static synchronized void initAvailableCurrencies() { | ||
if (available == null) { | ||
available = new HashSet<>(256); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not related to your change, but this should be HashSet.newHashSet(256)
. In fact 256*0.75 is 192, which is smaller than the current number of currencies (230, as of JDK24)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in c94ba94
* {@return a set of available currencies} The returned set of currencies | ||
* contains all the available currencies, which may include currencies | ||
* that represent obsolete ISO 4217 codes. If there is no currency available | ||
* in the runtime, the returned set is empty. The set can be modified |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An apiNote might be appropriate to refer/recommend using the new availableCurrencies()
API.
And/or an @see link to the method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Roger, incorporated both your suggestions in dcb4a9b. Note, I intentionally did not add any wording regarding the defensive copy in the apiNote
, considering that is an implementation specific caveat.
* available in the runtime, the returned stream is empty. | ||
* | ||
* @implNote Unlike {@link #getAvailableCurrencies()}, this method does | ||
* not create a defensive copy of the {@code Currency} set. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An @see link to getAvailableCurrencies
might be useful.
@Test | ||
public void streamEqualsSetTest() { | ||
var currencies = Currency.getAvailableCurrencies(); | ||
assertEquals(currencies, Currency.availableCurrencies().collect(Collectors.toSet())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally, a message describing the failure is more useful than just a stacktrace. (the 3rd arg on assertEquals override.)
It avoids needing to find the source code to create the bug report.
} | ||
|
||
// Initialize the set of available currencies if needed | ||
private static synchronized void initAvailableCurrencies() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we make available
volatile so we can avoid entering the monitor if the currencies are initialized?
(Note: We may get Stable Values very soon, at that point SV is a much better solution)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Chen, made available
volatile and implemented DCL in 96e86c8.
Also added a duplicate elements test as you suggested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how useful it is to optimize the performance of availableCurrencies
access to "available", but adding volatile will slow every access down.
The computation of the available currencies is stable, so a race computing it is benign.
Except for the available hashSet being partially filled when read by the thread calling getAvailableCurrencies()
.
That could be remedied by using a new local for the new HashSet in initAvailableCurrencies and assigning to available only when the set is completely initialized.
(And yes, this looks like a good fit for stable values.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about I revert the most recent commit and have this PR simply deliver the change to provide the stream of currencies. I'll file another issue to improve available
to use stable values when that is available. Does that sound fine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverted in ade21c9. Filed JDK-8348351 to implement available
as a stable value when applicable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect that Stable Values would fit well here.
var currencies = Currency.getAvailableCurrencies(); | ||
assertEquals(currencies, Currency.availableCurrencies().collect(Collectors.toSet()), | ||
"availableCurrencies() and getAvailableCurrencies() do not have the same elements"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a test to ensure Currency.availableCurrencies()
has no duplicate elements?
Currency.availableCurrencies().collect(Collectors.toMap(Function.identity(), Function.identity());
SpecialCaseEntry scEntry = specialCasesList.get(index); | ||
|
||
if (scEntry.cutOverTime == Long.MAX_VALUE | ||
|| System.currentTimeMillis() < scEntry.cutOverTime) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be better to obtain the current time once and compare against the same value for all entries rather than potentially using different current times for each comparison.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. I filed JDK-8348205 because that change would have its own behavioral concerns, which I don't want to overlap with this issue/CSR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR looks good in the current form. Since I am no professional in locale area, requesting another review from Naoto or Roger.
/reviewers 2 reviewer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could add @stable to available
for now, but forseeing the stable values, not that significant. So fine by me as in its current form
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@justin-curtis-lu this pull request can not be integrated into git checkout 8347949-Currency-Stream
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push |
Thanks all for the reviews. |
Going to push as commit f05c53c.
Your commit was automatically rebased without conflicts. |
@justin-curtis-lu Pushed as commit f05c53c. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Please review this PR and CSR which adds a method to java.util.Currency which returns a stream of the available Currencies.
The motivation can be found in the CSR.
Progress
Issues
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23165/head:pull/23165
$ git checkout pull/23165
Update a local copy of the PR:
$ git checkout pull/23165
$ git pull https://git.openjdk.org/jdk.git pull/23165/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 23165
View PR using the GUI difftool:
$ git pr show -t 23165
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23165.diff
Using Webrev
Link to Webrev Comment