review request: 8006505 additional updates for JSR 310
Ulf Zibis
Ulf.Zibis at CoSoCo.de
Wed Feb 6 14:26:02 UTC 2013
Am 06.02.2013 13:15, schrieb Lance Andersen - Oracle:
> I am going to change the message from
>
> "readObject not implemented"
>
> to "method readObject(Class<T>) not implemented"
There is 1 % missing to be perfect: "method <T> T readObject(Class<T> type) not implemented" ;-)
I was also thinking about this 100 % message, but I thought, exception messages should not be so
talkative/verbose. Additionally reduces class footprint and CPU cycles.
> As it was suggested to make it stand out from the other readObject method from another reviewer.
And thinking again, I think, that:
"SQLFeatureNotSupportedException at package.MyClass.callsite(MyClass.java:123)
would be clear enough, no big difference between "...NotSupported..." and "... not implemented".
In any case, the developer has to look at the call site at MyClass.java:123, where he clearly will
see, which method is not supported/implemented, ... so empty exception message should suffice here.
> I am just going to make the change then push later today
>>>> Have you observed internal review ID of 2426775?
>>> I have not seen this come through as of yet but will let you know when I do.
>> It was from 16.01.2013 15:19 +0100
> That was for your comment with the SQLInput/OuputImpl classes:
>
>
> ... and starting idx by 0 instead -1 would not be so exotic
This was only an aside remark, the main justification for my bug report is, that I still think,
method <T> T readObject(Class<T> type) is completely superfluous, if we generify the existing method.
> I have not seen the issue in our internal tracking system (but have not gone looking for it either). And as I mentioned in my response to your suggestion, I will look at this after I wrap up other work for JDBC 4.2 and RowSet 1.2
OK, I attach the report here:
Date Created: Wed Jan 16 07:19:27 MST 2013
Type: rfe
Customer Name: Ulf Zibis
Customer Email:Ulf.Zibis at CoSoCo.de
SDN ID:
status: Waiting
Category: java
Subcategory: jdbc
Company: CoSoCo
release: 7
hardware: x86
OSversion: win_xp
priority: 4
Synopsis: Generic accessors to SQLInput, SQLOutput
Description:
A DESCRIPTION OF THE REQUEST :
Currently, interfaces SQLInput, SQLOutput provide plenty accessors for distinct type, and one general read/writeObject().
The latter could be generified to cover all other non-primitive types, with the effect pushing the root of a possible ClassCastException to the call site layer.
The non-primitive distinct ones could be deprecated.
JUSTIFICATION :
- general convenience
- save the additional external cast for readObject()
- in the javax.sql.rowset.serial implementation, the dictinct accessors could internally cause a ClassCastException, which would be unfathomable for users
- less code to maintain, especially for future extensions
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
E.G.:
boolean bb = sqlInput.readBoolean();
Boolean b = sqlInput.readObject();
String s = sqlInput.readObject();
Blob bl = sqlInput.readObject();
...
ACTUAL -
E.G.:
boolean bb = sqlInput.readBoolean();
Boolean b = (Boolean)sqlInput.readObject();
String s = sqlInput.readString();
Blob bl = sqlInput.readBlob();
...
---------- BEGIN SOURCE ----------
proposed source changes for javax.sql.rowset.serial.SQLInputImpl
private int idx = 0; // init with 0 instead -1
private Object attribs[]; // rename attrib to attribs
public boolean readBoolean() throws SQLException {
Boolean attrib = readObject(); // replace old (Boolean)getNextAttribute()
return (attrib == null) ? false : attrib.booleanValue();
}
public <T> T readObject() throws SQLException {
if (idx >= attribs.length) {
throw new SQLException("SQLInputImpl exception: Invalid read " +
"position");
}
T attrib = (T)attribs[idx++];
lastValueWasNull = attrib == null;
if (attrib instanceof Struct) {
... // maybe move to extra method to enhance possibility
... // for JIT to compile + inline the main path
...
}
return attrib;
}
---------- END SOURCE ----------
workaround:
comments: (company - CoSoCo , email -Ulf.Zibis at CoSoCo.de)
-Ulf
More information about the core-libs-dev
mailing list