RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext
Please help review change to move the AbstractCharsetProvider from java.base/sun.nio.cs to jdk.charsets/sun.nio.cs.ext. This is needed for the modules. issue: https://bugs.openjdk.java.net/browse/JDK-8081452 webrev: http://cr.openjdk.java.net/~sherman/8081452 Thanks, -Sherman
On 29/05/2015 07:58, Xueming Shen wrote:
Please help review change to move the AbstractCharsetProvider from java.base/sun.nio.cs to jdk.charsets/sun.nio.cs.ext. This is needed for the modules.
issue: https://bugs.openjdk.java.net/browse/JDK-8081452 webrev: http://cr.openjdk.java.net/~sherman/8081452 This looks okay to me. I just wonder if it should we renamed too as it isn't abstract.
-Alan
It was originally written to be the base class for both std and ext charsets providers... maybe it should just be merged into the ExtendedCharsets class later separately. -sherman On 5/29/2015 12:04 AM, Alan Bateman wrote:
On 29/05/2015 07:58, Xueming Shen wrote:
Please help review change to move the AbstractCharsetProvider from java.base/sun.nio.cs to jdk.charsets/sun.nio.cs.ext. This is needed for the modules.
issue: https://bugs.openjdk.java.net/browse/JDK-8081452 webrev: http://cr.openjdk.java.net/~sherman/8081452 This looks okay to me. I just wonder if it should we renamed too as it isn't abstract.
-Alan
On 05/29/2015 12:20 AM, Xueming Shen wrote:
It was originally written to be the base class for both std and ext charsets providers... maybe it should just be merged into the ExtendedCharsets class later separately.
Perhaps better to merge it now rather than separately? Mandy
-sherman
On 5/29/2015 12:04 AM, Alan Bateman wrote:
On 29/05/2015 07:58, Xueming Shen wrote:
Please help review change to move the AbstractCharsetProvider from java.base/sun.nio.cs to jdk.charsets/sun.nio.cs.ext. This is needed for the modules.
issue: https://bugs.openjdk.java.net/browse/JDK-8081452 webrev: http://cr.openjdk.java.net/~sherman/8081452 This looks okay to me. I just wonder if it should we renamed too as it isn't abstract.
-Alan
On 05/29/2015 09:28 AM, Mandy Chung wrote:
On 05/29/2015 12:20 AM, Xueming Shen wrote:
It was originally written to be the base class for both std and ext charsets providers... maybe it should just be merged into the ExtendedCharsets class later separately.
Perhaps better to merge it now rather than separately?
But if it is decided later that we may want to have a separate ext charsets provider2, for example to split most of the ibm charsets to a separate provider, it might be desired to keep it as a base class ...
Am 29.05.2015 um 19:42 schrieb Xueming Shen:
But if it is decided later that we may want to have a separate ext charsets provider2, for example to split most of the ibm charsets to a separate provider, it might be desired to keep it as a base class ... Hm, is it mandatory, that each charset provider must have it's own class? I also think, that we do not need a separate class for each charset.
-Ulf
On 5/29/15 4:02 PM, Ulf Zibis wrote:
Am 29.05.2015 um 19:42 schrieb Xueming Shen:
But if it is decided later that we may want to have a separate ext charsets provider2, for example to split most of the ibm charsets to a separate provider, it might be desired to keep it as a base class ... Hm, is it mandatory, that each charset provider must have it's own class? I also think, that we do not need a separate class for each charset.
No, it's not a "must" to have a separate class for each charset, but it's a logical way to organize those charset with their data. Given how most of these charsets are src-generated in current jdk, it's fair easy to actually generate a "charset" object from a base classes (SingleByte, or DoubleByte) + a set of "data" ( such as the name, aliases table, mapping data, etc) during runtime, without having a real concrete charset class. But then you need to figure out a better way to organize, store and read/initialize those "data" in a optimized way to initialize each charset on the fly, which we are now utilizing the jvm's class initialization mechanism to achieve this. Any benefit/advantage of doing this? We might throw in some resource someday to gather some data ... -Sherman
Am 30.05.2015 um 03:26 schrieb Xueming Shen:
On 5/29/15 4:02 PM, Ulf Zibis wrote:
Am 29.05.2015 um 19:42 schrieb Xueming Shen:
But if it is decided later that we may want to have a separate ext charsets provider2, for example to split most of the ibm charsets to a separate provider, it might be desired to keep it as a base class ... Hm, is it mandatory, that each charset provider must have it's own class? I also think, that we do not need a separate class for each charset.
No, it's not a "must" to have a separate class for each charset, but it's a logical way to organize those charset with their data. Given how most of these charsets are src-generated in current jdk, it's fair easy to actually generate a "charset" object from a base classes (SingleByte, or DoubleByte) + a set of "data" ( such as the name, aliases table, mapping data, etc) during runtime, without having a real concrete charset class. But then you need to figure out a better way to organize, store and read/initialize those "data" in a optimized way to initialize each charset on the fly, which we are now utilizing the jvm's class initialization mechanism to achieve this. Any benefit/advantage of doing this? We might throw in some resource someday to gather some data ...
Hi sherman, I did some work here: https://bugs.openjdk.java.net/show_bug.cgi?id=100090 https://bugs.openjdk.java.net/show_bug.cgi?id=100091 https://bugs.openjdk.java.net/show_bug.cgi?id=100092 https://bugs.openjdk.java.net/show_bug.cgi?id=100095 https://bugs.openjdk.java.net/show_bug.cgi?id=100098 https://bugs.openjdk.java.net/show_bug.cgi?id=1000104 https://bugs.openjdk.java.net/show_bug.cgi?id=1000105 https://bugs.openjdk.java.net/show_bug.cgi?id=1000107 https://bugs.openjdk.java.net/show_bug.cgi?id=1000132 Unfortunately the data was moved somewhere. Do you know, where the data was moved? One of the original bug reports: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6862158 Also I did some work here: https://java.net/projects/java-nio-charset-enhanced -Ulf
participants (4)
-
Alan Bateman
-
Mandy Chung
-
Ulf Zibis
-
Xueming Shen