-
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
JDK-8316435: sun.util.calendar.CalendarSystem subclassing should be restricted #15803
JDK-8316435: sun.util.calendar.CalendarSystem subclassing should be restricted #15803
Conversation
👋 Welcome back jlu! A progress list of the required criteria for merging this PR into |
@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 overall.
public class CalendarUtils { | ||
public final class CalendarUtils { | ||
|
||
private CalendarUtils() {} |
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 may be obvious, but adding a comment would be helpful, i.e., no instance may be created.
static class Date extends BaseCalendar.Date { | ||
protected Date() { | ||
static final class Date extends BaseCalendar.Date { | ||
Date() { |
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 think removing protected
from the final
class methods is fine. Adding @Override
may be helpful.
long z = mod(x, y); | ||
return (z == 0) ? y : z; | ||
} | ||
|
||
/** | ||
* Mimics sprintf(buf, "%0*d", decaimal, width). | ||
*/ | ||
public static final StringBuilder sprintf0d(StringBuilder sb, int value, int width) { | ||
public static StringBuilder sprintf0d(StringBuilder sb, int value, int width) { |
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.
Can this (and the following overload) method be eliminated? No need to mimic sprintf
here, but using String.format
/formatted
should suffice?
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 for reviewing, replaced the two methods with Formatter (there are occurrences in test as well)
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.
Oh, I was not aware that the utility methods were used in Date.toString()
. I will have to take my suggestion back for performance reasons (assuming the existing implementation is faster). Sorry for not noticing that beforehand.
I added a question on https://bugs.openjdk.org/browse/JDK-8316435 as to the effect on future calendar systems. |
@justin-curtis-lu this pull request can not be integrated into git checkout JDK-8316435-seal-sun.util.calendar
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 |
@@ -59,7 +59,8 @@ | |||
* @author Masayoshi Okutsu | |||
* @since 1.5 | |||
*/ | |||
public abstract class CalendarDate implements Cloneable { | |||
public sealed abstract class CalendarDate implements Cloneable | |||
permits BaseCalendar.Date { |
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.
Can we just merge CalendarDate
and BaseCalendar.Date
to be the one class?
I think it will greatly simplify the code.
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.
BaseCalendar
is for Gregorian based calendars, so its Date
class also represents dates for those calendars, while CalendarDate
is an abstract class for all calendar implementations. So I don't think merging them is the right direction.
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 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 37 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 |
/integrate |
Going to push as commit 496264c.
Your commit was automatically rebased without conflicts. |
@justin-curtis-lu Pushed as commit 496264c. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Please review this PR which restricts sub-classing of the internal calendar system in sun.util.calendar to only the existing implementations. Drive by cleanup included.
As the implementation is long-standing and complete with no intent for future sub-classing, the CalendarSystem should be made sealed. Modifiers adjusted accordingly (
JulianCalendar.Date
must now have package visibility).This system has the following structure,
CalendarSystem
extended byAbstractCalendar
extended byBaseCalendar
extended by(
Gregorian, JulianCalendar, LocalGregorianCalendar
)CalendarDate
extended byBaseCalendar.Date
extended by(
Gregorian.Date, ImmutableGregorianDate, JulianCalendar.Date, LocalGregorianCalendar.Date
)Additionally, CalendarUtils was made
final
, as it is a utility class composed of static util methods.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/15803/head:pull/15803
$ git checkout pull/15803
Update a local copy of the PR:
$ git checkout pull/15803
$ git pull https://git.openjdk.org/jdk.git pull/15803/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 15803
View PR using the GUI difftool:
$ git pr show -t 15803
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/15803.diff
Webrev
Link to Webrev Comment