RFR: JDK-8073152: Update Standard/ExtendedCharsets to work with module system
erik.joelsson at oracle.com
Mon Feb 16 10:25:59 UTC 2015
* 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.
* The same issue with prerequisites not properly defined for
$(CHARSET_STANDARD_JAVA_TEMPLATES) and an unknown number of files in
$(CHARSET_EXTSRC_DIR) should be added for correct incremental build
On 2015-02-14 21:30, Xueming Shen wrote:
> 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
> (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
> (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
> (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.
More information about the build-dev