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?