Bug ID: JDK-8048123 Replace calendars.properties with another mechanism to specify a new Japanese calendar era

JDK-8048123 : Replace calendars.properties with another mechanism to specify a new Japanese calendar era

Type: Sub-task
Component: core-libs
Sub-Component: java.util:i18n
Affected Version: 9

Priority: P3
Status: Resolved
Resolution: Fixed
OS: generic
CPU: generic

Submitted: 2014-06-25
Updated: 2017-05-17
Resolved: 2014-08-07

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 9
9 b28Fixed

Related Reports

Relates :	JDK-8048124 - Read hijrah-config-umalqura.properties as a resource
Relates :	JDK-8039317 - Read currency.data as a resource
Relates :	JDK-8177776 - Create an equivalent test case for JDK9's SupplementalJapaneseEraTest
Relates :	JDK-8054214 - JapaneseEra.getDisplayName doesn't return names if it's an additional era

Description

This bug asks to examine calendars.properties files under ${java.home}/lib and understand if it is a configuration and whether it should be a resources file (in resources.jar). 

The motive for this bug is the modular JDK where we need the flexibility to put anything that is module-private into a module-private location. In this case it would appear that the above files are not a supported interface and so should move to a location that should be read as resources.

Comments

It no longer makes sense to have a properties file if properties can't be modifiable. There should be another mechanism to specify a new Japanese calendar era without updating a properties file.

30-06-2014