Yoko - CORBA Server
  1. Yoko - CORBA Server
  2. YOKO-409

Answer this question: Why does the code use a home-grown character set conversion algorithm and not nio.charset?

    Details

    • Type: Task Task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: Incubation
    • Fix Version/s: Incubation
    • Component/s: Web Site
    • Security Level: public (Regular issues)
    • Labels:
      None

      Description

      Document in wiki.

        Issue Links

          Activity

          Hide
          Wolfgang Glas added a comment -

          OK, I've undertaken a small code-review on this issue and have discovered the following points:

          1) There seems to be some hazzle about the semantics of a codeset converter:

          YOKO: char convert(char c)
          JRE: byte convert (char c) (resp. the stream-based API in CharsetDecoder/CharsetDecoder)

          YOKO: static CodeConvert getConverter (int fromCS, in toCS)
          JRE: static getCharset(String name)

          Mostly it seems, that YOKO is trying to implement a conversion from one charset to another.

          IMHO this has no sense within the confines of the IDL-to-JAVA mapping, which actually maps string and wstring argument to java.lang.String, an abstraction of 'a sequence of unicode characters'. Moreover, there's no such thing like a 'native charset' in JAVA, since the native charset in a C/C++ program denoted the codeset used to store the character data internally in char/wchar_t arrays.

          The current YOKO implementation could therefore even lead to a complete character mess, just consider talking from a server using ISO8859-5 to a client using ISO8859-9.

          2) Consequently, I think the native charset within yoko should one be used to construct a fallback encoding, if no encoding could be deduced from the peer's profile. Even more, the JRE abstraction of CharsetEncoder/CharsetDecoder as an interface for serializing/deserializing a unicode string to a byte-based stream exactly fits the needs of an ORB implementation with the restriction, that UTF-16 always has to be mapped to UTF-16BE.

          3) IMHO switching to a clean nio.charset implementation would be really benefitial and will help us to avoid problems.

          I will start implementing a patch right now, could please one of the project's maintainers step up for testing/reviewing my work?

          TIA,

          Wolfgang

          Show
          Wolfgang Glas added a comment - OK, I've undertaken a small code-review on this issue and have discovered the following points: 1) There seems to be some hazzle about the semantics of a codeset converter: YOKO: char convert(char c) JRE: byte convert (char c) (resp. the stream-based API in CharsetDecoder/CharsetDecoder) YOKO: static CodeConvert getConverter (int fromCS, in toCS) JRE: static getCharset(String name) Mostly it seems, that YOKO is trying to implement a conversion from one charset to another. IMHO this has no sense within the confines of the IDL-to-JAVA mapping, which actually maps string and wstring argument to java.lang.String, an abstraction of 'a sequence of unicode characters'. Moreover, there's no such thing like a 'native charset' in JAVA, since the native charset in a C/C++ program denoted the codeset used to store the character data internally in char/wchar_t arrays. The current YOKO implementation could therefore even lead to a complete character mess, just consider talking from a server using ISO8859-5 to a client using ISO8859-9. 2) Consequently, I think the native charset within yoko should one be used to construct a fallback encoding, if no encoding could be deduced from the peer's profile. Even more, the JRE abstraction of CharsetEncoder/CharsetDecoder as an interface for serializing/deserializing a unicode string to a byte-based stream exactly fits the needs of an ORB implementation with the restriction, that UTF-16 always has to be mapped to UTF-16BE. 3) IMHO switching to a clean nio.charset implementation would be really benefitial and will help us to avoid problems. I will start implementing a patch right now, could please one of the project's maintainers step up for testing/reviewing my work? TIA, Wolfgang

            People

            • Assignee:
              Unassigned
              Reporter:
              Alan Cabrera
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development