Current specdiffs for JDBC 4.2

[Lance Andersen - Oracle]

I am fine with making it JDBCType.   Keeping it JDBCType also lines up well with the JDBC PDF spec which refers to the entries in Types.java  as JDBC Types (such as in the Data Type conversions appendix)

Happy Holidays.

-Lance
On Dec 21, 2012, at 12:13 PM, Douglas Surber wrote:

> At the very least in needs to be JDBCType, not plural.
> 
> Douglas
> 
> 
> 
> At 03:45 PM 12/20/2012, Lance Andersen - Oracle wrote:
>> We had this discussion in August on the 221 list and given not all of the types are ANSI, such as ROWID, it was agreed at that time to leave the class name as is and highlight the types which correspond to ANSI types as such in the enum.  I am not keen on going from JDBCTypes -> ANSITypes.
>> 
>> If you have an alternate name besides ANSITypes we can consider that.
>> 
>> On Dec 20, 2012, at 6:01 PM, Douglas Surber wrote:
>> 
>> > The name JDBCTypes doesn't work for me. First it is a plural noun. Generally classes are singular nouns unless the class specifically represents a group of things such as Properties. We do have a class Types, but it is just a group of static final ints. Second the elements are not types that "belong" to JDBC somehow. They are the ANSI SQL types. ANSIType would be better.
>> >
>> > SQLType is the interface that spans all SQL types, ANSI and non-ANSI. ANSITypes would be the SQL types that are specified by the ANSI standard. If a vendor such as Oracle adds some additional types those would be listed in an enum named OracleType that implements SQLType. Further because the standard has java.sql.Types, Oracle has already added oracle.jdbc.OracleTypes. If the standard adds JDBCTypes, Oracle cannot use the parallel name since it is already used for another purpose.
>> >
>> > Douglas
>> >
>> >
>> > At 08:53 AM 12/18/2012, Lance Andersen - Oracle wrote:
>> >> Can be found at http://cr.openjdk.java.net/~lancea/8005080/specdiffs.00/. Currently I am having issues pulling over the openjdk website to update so from talking with Alan this made the most sense to do.
>> >>
>> >> There will be additional changes for 310 in which will add a couple of methods to java.sql Date, Time, Timestamp to aid in moving to/from LocalDate, LocalDateTime, LocalTime.   This will be done as part of the 310 integration work.  When310 integration is done, updates will also be added to Types.java and JDBCTypes.java
>> >>
>> >> No support for SQL Interval or the 310 Period will happen in this release as it is not a priority and we have to think it out more as Period does not quite line up with what we need for SQL Interval (and this is not a big priority from JDBC vendors)
>> >>
>> >> Additional minor cleanup and clarifications will probably happen in some of the other methods before the end game as time permits
>> >>
>> >> Best
>> >> Lance
>> >>
>> >>
>> >>
>> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> >> Oracle Java Engineering
>> >> 1 Network Drive
>> >> Burlington, MA 01803
>> >> Lance.Andersen at oracle.com
>> >
>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
> 

-------------- next part --------------

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com