Skip to content
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

8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate #7683

Closed
wants to merge 13 commits into from

Conversation

naotoj
Copy link
Member

@naotoj naotoj commented Mar 3, 2022

Supporting IsoFields temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change requires a CSR request to be approved
  • Change must be properly reviewed (1 review required, with at least 1 reviewer)

Issues

  • JDK-8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate
  • JDK-8282278: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate (CSR)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683
$ git checkout pull/7683

Update a local copy of the PR:
$ git checkout pull/7683
$ git pull https://git.openjdk.java.net/jdk pull/7683/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 7683

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/7683.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Mar 3, 2022

👋 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 openjdk bot added the rfr Pull request is ready for review label Mar 3, 2022
@openjdk
Copy link

openjdk bot commented Mar 3, 2022

@naotoj The following labels will be automatically applied to this pull request:

  • core-libs
  • i18n

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.

@openjdk openjdk bot added core-libs core-libs-dev@openjdk.org i18n i18n-dev@openjdk.org csr Pull request needs approved CSR before integration labels Mar 3, 2022
@mlbridge
Copy link

mlbridge bot commented Mar 3, 2022

@JoeWang-Java
Copy link
Member

Is the public API change, adding the isIsoLike() method, necessary? It seems to me we already have the isSupported method​ for that purpose and plus isSupportedBy​ from the IsoFields. Would making sure the IsoFields are supported at the implementation level be sufficient?

throw new DateTimeException("Resolve requires IsoChronology");
private static void ensureIsoLike(TemporalAccessor temporal) {
if (!isIsoLike(temporal)) {
throw new DateTimeException("Resolve requires ISO-like Chronology");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would the exception be easier to debug with if it mentioned the chronology that is not ISO-like?

}

@Test
public void test_Unit_isSupportedBy_ISO() {
assertEquals(IsoFields.WEEK_BASED_YEARS.isSupportedBy(LocalDate.now()),true);
assertEquals(IsoFields.WEEK_BASED_YEARS.isSupportedBy(ThaiBuddhistDate.now()),false);
assertEquals(IsoFields.WEEK_BASED_YEARS.isSupportedBy(ThaiBuddhistDate.now()),true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typically, comma (",") is followed by space.

@@ -677,6 +677,18 @@ public Period period(int years, int months, int days) {
return Period.of(years, months, days);
}

//-----------------------------------------------------------------------
/**
* {@inheritDoc}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather see the statement indicating that ISOChronology returns true; not a generic sentence.
(For each of the Chronologies).

"IsoChronology supports ISO based fields, such as DAY_OF_QUARTER and QUARTER_OF_YEAR."

* @see ThaiBuddhistChronology
* @since 19
*/
default boolean isIsoLike() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a bit late for a name change...

How about the method name being: supportsIsoFields().

IsoLike seem pretty wishy washy.

@naotoj naotoj closed this Mar 4, 2022
@naotoj naotoj reopened this Mar 4, 2022
@naotoj
Copy link
Member Author

naotoj commented Mar 4, 2022

Is the public API change, adding the isIsoLike() method, necessary?

Yes, I believe so. Without a means to tell whether the TemporalAccessor, such as LocalDate, supports IsoFields, IsoFields would have to hard-code which temporal accessor is supporting IsoFields fields.

* @see java.time.temporal.IsoFields
* @since 19
*/
default boolean supportsIsoFields() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a fan of this name, as it is inconsistent with the rest of JSR310 API, which uses an is prefix for booleans. I suggested isIsoLike because the key question is whether the chronology is "like" ISO. I would also be OK with isBasedOnIso, isDerivedFromIso, isIsoBased or something similar. Another risk here is limiting the method to refer only to IsoFields. While that is the use case here, it isn't the case that the only fields that might be affected are in IsoFields. Third parties may have their own fields that are suitable for use with an ISO-like chronology.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I propose isIsoBased() for the name, which I initially thought of. If there is no objection, I will modify the spec/impl.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is IsoBased is fine with me. "isISOLike" is too vague.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That matches the javadoc as well, that it "supports ISO based fields".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed the new method to isIsoBased(). Modified the CSR accordingly.

* @since 19
*/
@Override
public boolean isIsoBased() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this meant to be 'default'? The CSR indicated adding default methods.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default method has been added to java.time.chrono.Chronology interface. This is its overridden method implemented in IsoChronology concrete class.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make navigation easier, change the @code references to be @links and include the IsoField name.

I don't think the @implspec is needed, its redundant with @return.

Apply similar changes to the other ISO chronologies javadoc.

@bridgekeeper
Copy link

bridgekeeper bot commented Apr 4, 2022

@naotoj This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@JoeWang-Java
Copy link
Member

Looks good to me. For the name, another option might be IsoCompatible instead of IsoBased as historically those other calendars were established before the ISO standard, although technically, in the Java language, it could be said the xChronology is ISO based.

* @see IsoFields
* @since 19
*/
default boolean isIsoBased() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can the description be more specific. Each of the chronologies mentioned
say they have the same number of months, the number of days in each month, and day-of-year and leap years are the same as ISO. The week-based fields in IsoFields also depend ISO defined concepts.

Perhaps it should say that this method should return true only if all of the fields of IsoFields are supported for the chronology.

The chronology names could be links and omit the @see tags, including ISOChronology.

In the @return add ", otherwise return {@code false}."

* @since 19
*/
@Override
public boolean isIsoBased() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make navigation easier, change the @code references to be @links and include the IsoField name.

I don't think the @implspec is needed, its redundant with @return.

Apply similar changes to the other ISO chronologies javadoc.

private static void ensureIsoBased(TemporalAccessor temporal) {
if (!isIsoBased(temporal)) {
throw new DateTimeException("Resolve requires ISO based chronology: " +
Chronology.from(temporal));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name change doesn't add much, I'd leave both ensureIso and isIso method names unchanged.

static boolean isIso(TemporalAccessor temporal) {
return Chronology.from(temporal).equals(IsoChronology.INSTANCE);
static boolean isIsoBased(TemporalAccessor temporal) {
return Chronology.from(temporal).isIsoBased();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this method be private static?

Also, move the ensureIso method to be next to isIso.

Copy link
Contributor

@RogerRiggs RogerRiggs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks

@bridgekeeper
Copy link

bridgekeeper bot commented May 17, 2022

@naotoj This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

@openjdk openjdk bot removed the csr Pull request needs approved CSR before integration label May 20, 2022
@openjdk
Copy link

openjdk bot commented May 20, 2022

@naotoj 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:

8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate

Reviewed-by: joehw, rriggs

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 81 new commits pushed to the master branch:

  • 087bccf: 8286978: SIGBUS in libz during CDS initialization
  • 4587337: 8286858: Remove dead code in sun.reflect.misc.MethodUtil
  • 6d56caf: 8285962: NimbusDefaults has a typo in a L&F property
  • d5d19f5: 8287013: StringConcatFactory: remove short and byte mixers/prependers
  • 828dc89: 8286893: G1: Recent card set coarsening statistics wrong
  • 6569666: 8286943: G1: With virtualized remembered sets, maximum number of cards configured is wrong
  • 40e99a1: 8285308: Win: Japanese logical fonts are drawn with wrong size
  • 890771e: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character
  • de74e0e: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
  • 9f562ef: 8286872: Refactor add/modify notification icon (TrayIcon)
  • ... and 71 more: https://git.openjdk.java.net/jdk/compare/a31130fd4056907edcb420761722c629a33273eb...master

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 master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label May 20, 2022
@naotoj
Copy link
Member Author

naotoj commented May 23, 2022

/integrate

@openjdk
Copy link

openjdk bot commented May 23, 2022

Going to push as commit ef7a9f8.
Since your change was applied there have been 104 commits pushed to the master branch:

  • ac274c4: 8286956: Loom: Define test groups for development/porting use
  • 5d8d6da: 8286972: Support the new loop induction variable related PopulateIndex IR node on x86
  • 8122466: 8287113: JFR: Periodic task thread uses period for method sampling events
  • 940e94f: 8285739: disable EscapeBarrier deopt for virtual threads
  • 110d906: 8287103: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java fails with Xcomp
  • 8040aa0: 8286908: ECDSA signature should not return parameters
  • 689f80c: 8287153: Whitespace typos in HeapRegion class
  • c906591: 8286391: Address possibly lossy conversions in jdk.compiler
  • 88018c4: 8287150: Remove HeapRegion::block_start_const declaration without definition
  • 81f128b: 8287154: java/nio/channels/FileChannel/LargeMapTest.java does not compile
  • ... and 94 more: https://git.openjdk.java.net/jdk/compare/a31130fd4056907edcb420761722c629a33273eb...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label May 23, 2022
@openjdk openjdk bot closed this May 23, 2022
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 23, 2022
@openjdk
Copy link

openjdk bot commented May 23, 2022

@naotoj Pushed as commit ef7a9f8.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core-libs core-libs-dev@openjdk.org i18n i18n-dev@openjdk.org integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

4 participants