Re: [jira] Commented: (DERBY-1417) Add new, lengthless overloads to the streaming api

Wed, 26 Jul 2006 04:39:39 -0700 

Hello Kristian.

Oops ....
Sorry for the wrong name and confusion.
As you told, it is not UTF-32BE but UTF-16BE and it is me who named it ....

Well ....
How about prepare different class method of EncodedInputStream to instantiate objects for each encoding ? 
like as :
public static EncodedInputStream createUTF16BEEncodedInputStream(Reader reader) public static EncodedInputStream createUTF8EncodedInputStream(Reader reader)
I think encodings and appropriate size of buffer for each encoding should be placed in a structure... 

Best regards.


Kristian Waagan (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1417?page=comments#action_12423610 ] Kristian Waagan commented on DERBY-1417: 
----------------------------------------

Hi Tomohito,

Are you talking about the buffer for the PublicBufferOutputStream (which is a 
subclass of ByteArrayOutputStream)?
I agree it might not be optimal, but ByteArrayOutputStream grows the buffer as 
needed. If we are reading chars outside ISO-8859-1, the ByteArrayOutputStream 
would have to double its internal buffer once for every 1024 characters we read 
(from 2048 bytes to 4096 bytes).
My take on this, is that a separate Jira should be logged for this issue if it 
is worth optimizing/analyzing.

Also, I was very confused by the naming of the file UTF32BEEncodedInputStream 
and its comments. I found that it actually used the encoding 
UnicodeBigUnmarked, which is the Java name for UTF-16BE. But the name and the 
comments claimed UTF-32BE was used.

As for the subclasses, I thought about this, but decided not to do it, since 
the class is completely internal. If we do it, however, we can make the one for 
UnicodeBigUnmarked package private, and the UTF8 one public, since the latter 
one is the only one used outside the client/net package. I also thought about 
ways to restrict the available encodings, but again, this is an internal class 
and we should be able to choose only standard encodings (always available in 
Java). I mentioned this in the class comment. If you feel strongly about this, 
I can make 3 classes (please let me know).


Thanks for looking at the patch :)

BTW: My derbyalls showed a lot of unrelated errors (I got 18 total with 1.6), 
so I need time to study the results before I post anything. However,  with 1.4 
I only got a few known issues.


Add new, lengthless overloads to the streaming api
--------------------------------------------------

               Key: DERBY-1417
               URL: http://issues.apache.org/jira/browse/DERBY-1417
           Project: Derby
        Issue Type: New Feature
        Components: JDBC
  Affects Versions: 10.2.0.0
          Reporter: Rick Hillegas
       Assigned To: Kristian Waagan
           Fix For: 10.2.0.0

       Attachments: derby-1417-01-castsInTests.diff, 
derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff, 
derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat, 
derby-1417-6a-clientimpl.diff, derby-1417-6a-clientimpl.stat


The JDBC4 Expert Group has approved a new set of overloads for the streaming 
methods. These overloads do not take a length argument. Here are the new 
overloads:
PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader reader)
PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader reader)
PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
CallableStatement.setAsciiStream(java.lang.String parameterName, 
java.io.InputStream x)
CallableStatement.setBinaryStream(java.lang.String parameterName, 
java.io.InputStream x)
CallableStatement.setCharacterStream(java.lang.String parameterName, 
java.io.Reader reader)
CallableStatement.setNCharacterStream(java.lang.String parameterName, 
java.io.Reader reader)
CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream 
inputStream)
CallableStatement.setClob(java.lang.String parameterName, java.io.Reader reader)
CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader 
reader)
ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream x)
ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
ResultSet.updateBinaryStream(java.lang.String columnLabel, java.io.InputStream 
x, int length)
ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader x)
ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x)
ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader x) ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream) 
ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream 
inputStream)
ResultSet.updateClob(int columnIndex, java.io.Reader reader)
ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader)
ResultSet.updateNClob(int columnIndex, java.io.Reader reader)
ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader)
We should add these new overloads soon so that the build will not break when 
this methods turn up in a published Mustang build.




--
/*

       Tomohito Nakayama
       [EMAIL PROTECTED]
       [EMAIL PROTECTED]
       [EMAIL PROTECTED]

       Naka
       http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/

Reply via email to