RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with module system

[Erik Joelsson]

(adding build-dev)

Hello Sherman,

In Gensrc-jdk.charsets.gmk:
* The variable CHARSET_EXTENDED is defined but never used. The value is 
used in several places however. I think you should either use the 
variable or not define it at all.
* $(CHARSET_EXTENDED_DATA) is put on a prerequisite line, but the 
variable is not defined.
* The recipe for $(CHARSET_DONE_CS)-extcs uses $(CHARSET_STANDARD_OS), 
$(CHARSET_EXTENDED_JAVA_TEMPLATES) and the directory 
$(CHARSET_EXTENDED_JAVA_DIR), but none of these are listed as 
prerequisites. I should think touching any of these files (and which 
files in $(CHARSET_EXTENDED_JAVA_DIR)?) should trigger a rebuild of 
$(CHARSET_DONE_CS)-extcs so they should be added to the prerequisites.

In Gensrc-jdk.CharsetMapping.gmk:
* The same issue with prerequisites not properly defined for 
$(CHARSET_DONE_BASE)-stdcs. $(CHARSET_STANDARD_OS), 
$(CHARSET_STANDARD_JAVA_TEMPLATES) and an unknown number of files in 
$(CHARSET_EXTSRC_DIR) should be added for correct incremental build 
behavior.

/Erik

On 2015-02-14 21:30, Xueming Shen wrote:
> Hi,
>
> Please help review the changes for  JDK-8073152
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8073152
> Webrev: http://cr.openjdk.java.net/~sherman/8073152/webrev/
>
> This change is to re-organize how the "standard" and "extended" 
> charsets repository are
> built for the jdk/jre images. Before module system, the "standard" 
> charset provider is built
> into rt.jar and the "extended" charsets provider is in charsets.jar, 
> which is located in the
> "lib/ext" directory. both are available during the system boot time. 
> In jigsaw, the extended
> charsets provider is in jdk.charset (vs the "standard" is in 
> java.base) module and might not
> be "visible" during the early phase of system classes loading, which 
> might cause problem
> as some of the charsets now in "extended" charsets may needed during 
> the boot stage. The
> proposed change here is to re-organize the way these two providers are 
> built, and put in the
> mechanism that enable the build system to configure which group of 
> charsets need to be
> moved from the "extended" charsets into the "standard" (java.base), 
> based on the target
> platform, during the jdk build time.
>
> The updates are
>
> (1) to consolidate the existing configuration files "sbcs", "dbcs", 
> "extsbcs" and
>      "standard-charsets" (and the aliases table originally hardcoded 
> in ExtendeardCharsets.java)
>       into a single configuration file "charsets" to define all 
> supported charsets, with their
>       name, clz name,  history name, package name and all aliases
> http://cr.openjdk.java.net/~sherman/8073152/webrev/make/data/charsetmapping/charsets.html 
>
>
> (2) in addition to the the "standard charsets" provider, now the 
> "extended charsets" provider
>      class is also built during the build time based on the new 
> configuration file "charsets"
>
> (3) to add a build-time mechanism to specify individual sun.nio.cs.ext 
> charset to be built into
>      "standard" charsets provider (sun.nio.cs package in java.base 
> module), with os-specific
>       configuration file, such as stdcs-linux, stdcs-windows and 
> stdcs-solaris.
>
> (4) to move DoubleByte, HKSCS and DelegatableDecoder classes into 
> sun.nio.cs, so they can be
>      used/referenced by those dbcs classes that might be moved into 
> sun.nio.cs
>
> (5) to change some sun.nio.cs.ext implementation java files to be a 
> ".template", so the real .java
>      can be generated during build-time with correct pkg name and 
> aliases info.
>
> There are two leftover, gb18030 and euc_tw, these are two charsets 
> with huge mapping table. Might
> need special update to better fit into sun.nio.cs later.
>
> thanks!
> -Sherman