Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
Daniel John Debrunner (JIRA) derby-dev@db.apache.org writes: [ http://issues.apache.org/jira/browse/DERBY-1283?page=comments#action_12377662 ] Daniel John Debrunner commented on DERBY-1283: -- Seems strange to implement a deprecated api. Section 6.7 says Deprecation refers to a class, interface, constructor, method or field that is no longer recommended and may cease to exist in a future version. Why would Derby implement a method we don't want applications to use? Perhaps because the same method is described in Derby's own documentation? :) Reference guide (Alpha manuals) - JDBC - PreparedStatement - PreparedStatements and streaming columns Did this method perhaps exist at some point, and was then later removed? Now that we have persuaded the EG to make the method optional, perhaps we should get our own house in order, as it were, and update the documentation? If nobody objects I'll create a doc jira for this. -- dt
Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
Prior versions of the JDBC specification were not clear or concise as to what a developer and or a user could expect. This as a JDBC driver developer while at Sybase i found extremely frustrating. These methods have been in the JDBC spec since 1.0. We will not be removing them from the spec and just because something is deprecated, it does not mean that it should not be implemented or ignored. It just means that there are alternative methods that are recommended. Also in my working with the Java SE team, they discourage deprecating methods via the javadoc tag as it adds unnecessary noise at compile time where as a simple note in the spec/javadoc can point users to the preferred method. As far as your question below, it is impossible to determine what methods are and are not required from the JDBC 3.0 specification. This is something that i have addressed in JDBC 4.0. -lance Daniel John Debrunner wrote: Lance J. Andersen wrote: Very simple, just because it is deprecated, it does not mean it can be ignored. Bottom line, it is required to be there. According to which section of JDBC 3.0? Dan.
Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
Actually the intent has always been there, just not clearly articulated. If a driver claims to support a data type such as Blob/Clob/Array...etc... it is expected that all methods on the interface are fully implemented and just do not throw an exception. It is just JDBC 4.0 that i am taking the time to make this clearer. If your driver or backend does not support the datatype then all methods on the interface must throw SQLFeatureNotSupportedException for JDBC 4 and SQLException for JDBC 3. Daniel John Debrunner wrote: Lance J. Andersen wrote: The compliance chapter has seen significant clarifications for JDBC 4 to clarify what is and is not required. If you implement and interface for a data type such as blob/clob all methods must be implemented otherwise you do not support the data type. So this is a JDBC 4.0 requirement, not a JDBC 3.0 requirement. Just trying to understand. Dan.
Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
Daniel John Debrunner wrote: Lance J. Andersen wrote: The compliance chapter has seen significant clarifications for JDBC 4 to clarify what is and is not required. If you implement and interface for a data type such as blob/clob all methods must be implemented otherwise you do not support the data type. Is this a recent change to JDBC 4.0? I have a copy dated March 17th 2006 and I cannot see any significant changes to the Compliance chapter. I have not release the Proposed Final Draft to the JCP and there have been many updates to the compliance chapter since that version you have in your hand. I do see this sentence (section 6.7 Java EE JDBC compliance): "Support for the BLOB, CLOB, ARRAY, REF, STRUCT, and JAVA_OBJECT types is not required." So, why would full support for Blob be required for JDBC 4.0 compliance, if BLOB support is not required for Java EE JDBC and JDBC 4.0 compliance. It is only required if you claim support for the data type in your driver. What we do not want is you to say u support Clobs but only implement the methods on the interface that you happen to like. We want to provide a consistent api where users know what to expect. I'm just try to ensure that we are not trying to implement more than is required for JDBC 4.0 compliance, if we end up pushing against a Sep/Oct deadline for a Derby release with JDBC 4.0. Again, if you choose to not claim to support these data types, you do not need to implement the interfaces However to claim support and not implement all methods for a given data type is of limited value and makes it even more difficult to port apps from other databases to a given database I'm also asking for reference numbers (e.g. section numbers) as we just recently had a problem where the GRANT/REVOKE functional spec stated that something was one way according to the SQL spec. It turned out that the statement was incorrect, and lead to wasted time effort. Adding references to the specification to backup facts makes it much easier for others to verify. The JDBC spec consists of the paper spec and the javadocs. The compliance chapter articulates the requirements i list above in the working version of the PFD. Thanks, Dan.
Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
Lance J. Andersen wrote: Prior versions of the JDBC specification were not clear or concise as to what a developer and or a user could expect. This as a JDBC driver developer while at Sybase i found extremely frustrating. These methods have been in the JDBC spec since 1.0. We will not be removing them from the spec and just because something is deprecated, it does not mean that it should not be implemented or ignored. It just means that there are alternative methods that are recommended. Also in my working with the Java SE team, they discourage deprecating methods via the javadoc tag as it adds unnecessary noise at compile time where as a simple note in the spec/javadoc can point users to the preferred method. So the @deprecated tag is now deprecated! :-) As far as your question below, it is impossible to determine what methods are and are not required from the JDBC 3.0 specification. This is something that i have addressed in JDBC 4.0. DJD question According to which section of JDBC 3.0? Then this is about JDBC 4.0 compliance and not JDBC 3.0. I don't see how you can change the rules for JDBC 3.0 compliance with a release of the JDBC 4.0 specification. I believe that Sun in the past has confirmed JDBC drivers including Derby Cloudscape pre-open source as being JDBC 3.0 compliant, seems wrong to say, oh now there's additional work to do. Dan.
Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
DJD question According to which section of JDBC 3.0? Then this is about JDBC 4.0 compliance and not JDBC 3.0. yes and no, the intent has always been there just not clear in print If you feel more comfortable stating this is JDBC4 so be it, but again the intent has always been there, i am just making sure the points are highlighted I don't see how you can change the rules for JDBC 3.0 compliance with a release of the JDBC 4.0 specification. I believe that Sun in the past has confirmed JDBC drivers including Derby Cloudscape pre-open source as being JDBC 3.0 compliant, seems wrong to say, oh now there's additional work to do. There has never been a TCK to validate JDBC compliance end to end. What there has been is a test suite to validate the requirements of a JDBC driver in a J2EE environment. and the latest version is for J2EE 1.3 with JDBC 2.x. Passing this allows for a tagline to be used by driver vendors. Dan.
[jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
[ http://issues.apache.org/jira/browse/DERBY-1283?page=comments#action_12377820 ] Rick Hillegas commented on DERBY-1283: -- Dan's comment kicked off a lively discussion on derby-dev, under the subject line [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream(). I would like to capture some of that discussion here. Lance says: Very simple, just because it is deprecated, it does not mean it can be ignored. Bottom line, it is required to be there. There are no plans to remove these methods from JDBC. Lance continues later on: Prior versions of the JDBC specification were not clear or concise as to what a developer and or a user could expect. This as a JDBC driver developer while at Sybase i found extremely frustrating. These methods have been in the JDBC spec since 1.0. We will not be removing them from the spec and just because something is deprecated, it does not mean that it should not be implemented or ignored. It just means that there are alternative methods that are recommended. Also in my working with the Java SE team, they discourage deprecating methods via the javadoc tag as it adds unnecessary noise at compile time where as a simple note in the spec/javadoc can point users to the preferred method. As far as your question below, it is impossible to determine what methods are and are not required from the JDBC 3.0 specification. This is something that i have addressed in JDBC 4.0. Dan then notes: Then this is about JDBC 4.0 compliance and not JDBC 3.0. I don't see how you can change the rules for JDBC 3.0 compliance with a release of the JDBC 4.0 specification. I believe that Sun in the past has confirmed JDBC drivers including Derby Cloudscape pre-open source as being JDBC 3.0 compliant, seems wrong to say, oh now there's additional work to do. To which Lance responds: There has never been a TCK to validate JDBC compliance end to end. What there has been is a test suite to validate the requirements of a JDBC driver in a J2EE environment. and the latest version is for J2EE 1.3 with JDBC 2.x. Passing this allows for a tagline to be used by driver vendors. Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream() - Key: DERBY-1283 URL: http://issues.apache.org/jira/browse/DERBY-1283 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 For JDBC3 compliance, implement this method. Right now it throws a NotImplemented exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
What does deprecation mean for JDBC? (Was Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream())
Daniel John Debrunner wrote: We will not be removing them from the spec and just because something is deprecated, it does not mean that it should not be implemented or ignored. It just means that there are alternative methods that are recommended. Wow! This is not how I understood the word deprecation. I looked it up on wikipedia because I thought maybe I was using it wrong all these years. I am a big fan of a *very *long deprecation period, but I never imagined that new drivers would need to implement deprecated methods. *http://en.wikipedia.org/wiki/Deprecation* In computer software http://en.wikipedia.org/wiki/Computer_software standards and documentation, *deprecation* is the gradual phasing-out of a software or programming language http://en.wikipedia.org/wiki/Computer_programming_language feature. A feature or method marked as deprecated is one which is considered obsolete, and whose use is discouraged. The feature still works in the current version of the software, although it may raise error messages http://en.wikipedia.org/wiki/Error_message as warnings. These serve to alert the user to the fact that the feature may be removed in future releases. Is there some official language around what deprecation means for the JDBC API? Kathey
Re: What does deprecation mean for JDBC? (Was Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream())
I really do not want a war of words here as it serves zero purpose. Methods that are deprecated are never guaranteed to be removed though it is possible they could. There are no plans to remove any methods that are deprecated from JDBC and going forward unless there is a method that is severely broken/dangerous, it will not be marked deprecated, but instead a note explaining the preferred method will be added to the spec/javadocs. If you want to ask the question a different way and revisit whether setUniCodeStream can be considered optional, then do so please and i will consider it and have that discussion with the EG. JDBC drivers that have been around since the early days implemented this method. In compatibility testing, we do not remove or exclude tests just because something was deprecated, as long as the method is in the spec it is expected to function. JDBC is probably one of the poorer specs in this regard which is something i am working diligently to address. Kathey Marsden wrote: Daniel John Debrunner wrote: We will not be removing them from the spec and just because something is deprecated, it does not mean that it should not be implemented or ignored. It just means that there are alternative methods that are recommended. Wow! This is not how I understood the word deprecation. I looked it up on wikipedia because I thought maybe I was using it wrong all these years. I am a big fan of a *very *long deprecation period, but I never imagined that new drivers would need to implement deprecated methods. *http://en.wikipedia.org/wiki/Deprecation* In computer software http://en.wikipedia.org/wiki/Computer_software standards and documentation, *deprecation* is the gradual phasing-out of a software or programming language http://en.wikipedia.org/wiki/Computer_programming_language feature. A feature or method marked as deprecated is one which is considered obsolete, and whose use is discouraged. The feature still works in the current version of the software, although it may raise error messages http://en.wikipedia.org/wiki/Error_message as warnings. These serve to alert the user to the fact that the feature may be removed in future releases. Is there some official language around what deprecation means for the JDBC API? Kathey
Re: What does deprecation mean for JDBC? (Was Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream())
Rick Hillegas wrote: Lance J. Andersen wrote: ... If you want to ask the question a different way and revisit whether setUniCodeStream can be considered optional, then do so please and i will consider it and have that discussion with the EG. JDBC drivers that have been around since the early days implemented this method. I think this would be a useful discussion to have with the EG. It would be great if deprecation made a method optional even though the method remained in the api. I agree that it would be a good discussion to have and honestly I don't have a strong opinion one way or another about how it should be. I do think that regardless of whether deprecation makes a method optional or not, it would be really good to have clear wording somewhere saying that it does or does not. I am guessing there are folks that are just as in the dark as I have been that deprecated but mandatory methods exist. Kathey
[jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
[ http://issues.apache.org/jira/browse/DERBY-1283?page=comments#action_12377662 ] Daniel John Debrunner commented on DERBY-1283: -- Seems strange to implement a deprecated api. Section 6.7 says Deprecation refers to a class, interface, constructor, method or field that is no longer recommended and may cease to exist in a future version. Why would Derby implement a method we don't want applications to use? Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream() - Key: DERBY-1283 URL: http://issues.apache.org/jira/browse/DERBY-1283 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 For JDBC3 compliance, implement this method. Right now it throws a NotImplemented exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
[ http://issues.apache.org/jira/browse/DERBY-1283?page=comments#action_12377663 ] Daniel John Debrunner commented on DERBY-1283: -- Also, which section of JDBC 3.0 spec indicates that Derby is not currently in compliance with JDBC 3.0 with respect to this method. The method is implemented. It is implemented by throwing a SQLException because the database engine does not support the feature. Section 6.3 says the driver must include an implementation of PreparedStatement/ResultSet but does not say it must fully implement the interface. C.f. the comment in 6.3 for java.sql.Driver Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream() - Key: DERBY-1283 URL: http://issues.apache.org/jira/browse/DERBY-1283 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 For JDBC3 compliance, implement this method. Right now it throws a NotImplemented exception. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
Very simple, just because it is deprecated, it does not mean it can be ignored. Bottom line, it is required to be there. There are no plans to remove these methods from JDBC. Daniel John Debrunner (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1283?page=comments#action_12377662 ] Daniel John Debrunner commented on DERBY-1283: -- Seems strange to implement a deprecated api. Section 6.7 says "Deprecation refers to a class, interface, constructor, method or field that is no longer recommended and may cease to exist in a future version." Why would Derby implement a method we don't want applications to use? Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream() - Key: DERBY-1283 URL: http://issues.apache.org/jira/browse/DERBY-1283 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 For JDBC3 compliance, implement this method. Right now it throws a NotImplemented exception.
Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
The compliance chapter has seen significant clarifications for JDBC 4 to clarify what is and is not required. If you implement and interface for a data type such as blob/clob all methods must be implemented otherwise you do not support the data type. Daniel John Debrunner (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1283?page=comments#action_12377663 ] Daniel John Debrunner commented on DERBY-1283: -- Also, which section of JDBC 3.0 spec indicates that Derby is not currently in compliance with JDBC 3.0 with respect to this method. The method is implemented. It is implemented by throwing a SQLException because the database engine does not support the feature. Section 6.3 says the driver must include an implementation of PreparedStatement/ResultSet but does not say it must fully implement the interface. C.f. the comment in 6.3 for java.sql.Driver Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream() - Key: DERBY-1283 URL: http://issues.apache.org/jira/browse/DERBY-1283 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 For JDBC3 compliance, implement this method. Right now it throws a NotImplemented exception.
Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
Lance J. Andersen wrote: Very simple, just because it is deprecated, it does not mean it can be ignored. Bottom line, it is required to be there. According to which section of JDBC 3.0? Dan.
Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
Lance J. Andersen wrote: The compliance chapter has seen significant clarifications for JDBC 4 to clarify what is and is not required. If you implement and interface for a data type such as blob/clob all methods must be implemented otherwise you do not support the data type. So this is a JDBC 4.0 requirement, not a JDBC 3.0 requirement. Just trying to understand. Dan.
Re: [jira] Commented: (DERBY-1283) Fill in a deprecated but mandatory JDBC3 method: PreparedStatement.setUnicodeStream()
Lance J. Andersen wrote: The compliance chapter has seen significant clarifications for JDBC 4 to clarify what is and is not required. If you implement and interface for a data type such as blob/clob all methods must be implemented otherwise you do not support the data type. Is this a recent change to JDBC 4.0? I have a copy dated March 17th 2006 and I cannot see any significant changes to the Compliance chapter. I do see this sentence (section 6.7 Java EE JDBC compliance): Support for the BLOB, CLOB, ARRAY, REF, STRUCT, and JAVA_OBJECT types is not required. So, why would full support for Blob be required for JDBC 4.0 compliance, if BLOB support is not required for Java EE JDBC and JDBC 4.0 compliance. I'm just try to ensure that we are not trying to implement more than is required for JDBC 4.0 compliance, if we end up pushing against a Sep/Oct deadline for a Derby release with JDBC 4.0. I'm also asking for reference numbers (e.g. section numbers) as we just recently had a problem where the GRANT/REVOKE functional spec stated that something was one way according to the SQL spec. It turned out that the statement was incorrect, and lead to wasted time effort. Adding references to the specification to backup facts makes it much easier for others to verify. Thanks, Dan.
