-
Bug
-
Resolution: Fixed
-
P2
-
5.0
-
rc
-
generic
-
generic
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2082615 | 5.0 | Lance Andersen | P2 | Closed | Fixed | rc |
Name: nl37777 Date: 04/09/2004
Several methods in the rowset API and implementation have
specifications of the form "The byte format of the Unicode stream must
be Java UTF-8, as defined in the Java Virtual Machine Specification."
These seem inappropriate, although for different reasons for the
different methods:
- In the case of javax.sql.BaseRowset.setCharacterStream, the method
accepts a Reader. Readers don't produce byte streams, but char streams.
Their implementations (e.g., InputStreamReader) may consume byte
streams, but it doesn't seem necessary to specify these byte streams in
an API that only accepts a Reader. Can this sentence be removed from
this method?
- In the case of the com.sun.rowset.JdbcRowSetImpl.getUnicodeStream
methods, which do return byte streams, it still seems odd to require
the modified UTF-8 that's used in the JVM. Modified UTF-8 is intended
only for use within Java, it's incompatible with standard UTF-8, and as
far as I know, modern data bases use standard UTF-8 (there's also
CESU-8, which is an older form of UTF-8 and incompatible with both
standard and modified UTF-8, but I think vendors are trying to get away
from that). On the other hand, the implementation of these methods
relies on java.sql.ResultSet.getUnicodeStream, whose specification
requires yet a different incompatible encoding, UTF-16BE.
======================================================================
Several methods in the rowset API and implementation have
specifications of the form "The byte format of the Unicode stream must
be Java UTF-8, as defined in the Java Virtual Machine Specification."
These seem inappropriate, although for different reasons for the
different methods:
- In the case of javax.sql.BaseRowset.setCharacterStream, the method
accepts a Reader. Readers don't produce byte streams, but char streams.
Their implementations (e.g., InputStreamReader) may consume byte
streams, but it doesn't seem necessary to specify these byte streams in
an API that only accepts a Reader. Can this sentence be removed from
this method?
- In the case of the com.sun.rowset.JdbcRowSetImpl.getUnicodeStream
methods, which do return byte streams, it still seems odd to require
the modified UTF-8 that's used in the JVM. Modified UTF-8 is intended
only for use within Java, it's incompatible with standard UTF-8, and as
far as I know, modern data bases use standard UTF-8 (there's also
CESU-8, which is an older form of UTF-8 and incompatible with both
standard and modified UTF-8, but I think vendors are trying to get away
from that). On the other hand, the implementation of these methods
relies on java.sql.ResultSet.getUnicodeStream, whose specification
requires yet a different incompatible encoding, UTF-16BE.
======================================================================
- backported by
-
JDK-2082615 Inappropriate character encoding specifications
- Closed