The JCK and RowSet TCK will have base tests to validate. I have a separate set of unit tests for JDBC which includes more detailed tests than what you had suggested as well as end to end tests.
Best Lance On Jan 10, 2013, at 8:24 AM, Deven You wrote: > Hi Lance, > > I am glad to see the patch for implementing these methods are committed. > > Do you have a plan to add the test cases[1] I created too? > > Thanks a lot! > > [1]http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ > > > On 01/10/2013 08:31 PM, Lance Andersen - Oracle wrote: >> Deven, >> >> This was pushed a while ago you should have seen the putback on the alias >> >> See http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a8978a5bb6e >> >> Best >> Lance >> >> >> On Jan 10, 2013, at 12:49 AM, Deven You wrote: >> >>> Hi Lance, >>> >>> Is there any update for this issue. If you have anything I can do, please >>> let me know. >>> >>> Thanks a lot! >>> On 11/24/2012 12:45 AM, Lance Andersen - Oracle wrote: >>>> It is on my list. to update the javadocs I need a ccc which I have not >>>> done yet and is needed as part of this change >>>> >>>> On Nov 23, 2012, at 3:07 AM, Deven You wrote: >>>> >>>>> Hi Lance, >>>>> >>>>> Is there any plan for this issue, if any could you update to me? >>>>> >>>>> Thanks a lot! >>>>> On 10/29/2012 06:39 PM, Lance Andersen - Oracle wrote: >>>>>> Hi Deven, >>>>>> >>>>>> I will address the needed updates a bit later. >>>>>> >>>>>> Thank you for your input >>>>>> >>>>>> Best >>>>>> Lance >>>>>> On Oct 29, 2012, at 3:51 AM, Deven You wrote: >>>>>> >>>>>>> Hi Alan, >>>>>>> >>>>>>> The Java Spec does not mention the thread safe for JDBC API. But I see >>>>>>> the other code in SerialBlob/SerialClob have not consider it. >>>>>>> >>>>>>> I think use buff == null to replace isFree is a good idea because it >>>>>>> also avoid the problem for the condition buf == null && isFree == false >>>>>>> so we won't need create a readObject method. >>>>>>> >>>>>>> Thanks for your suggestion for isFree, I will correct it later. >>>>>>> >>>>>>> Lance: How about your suggestion? Since you mentioned you will develop >>>>>>> the implementation yourself. I use my implementation mainly for the >>>>>>> test cases. But you may also take a look my implementation. >>>>>>> >>>>>>> Thanks a lot! >>>>>>> >>>>>>> On 09/21/2012 04:37 PM, Alan Bateman wrote: >>>>>>>> On 21/09/2012 04:21, Deven You wrote: >>>>>>>>> Hi Lance, >>>>>>>>> >>>>>>>>> I am very busy with other work so I can't work with the >>>>>>>>> SerialBlob/SerialClob item for long time. I am very happy to refine >>>>>>>>> the current test case and create new tests for SerialClob. >>>>>>>>> >>>>>>>>> I have create a new webre[1] for this task, please review it. >>>>>>>>> >>>>>>>>> [1]http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ >>>>>>>>> <http://cr.openjdk.java.net/%7Eyoudwei/OJDK-576/webrev.01/> >>>>>>>>> >>>>>>>>> PS: If the isFree is not transient, I want to know how we add this >>>>>>>>> field to the javadoc serialized form? >>>>>>>> I don't know very much about the rowset API and I can't see anything >>>>>>>> to specify whether it is meant to be safe for use by concurrent >>>>>>>> threads. There are clearly lots of issues here and implementing free >>>>>>>> introduces a lot more, especially with the possibility of an >>>>>>>> asynchronous free or more than one thread calling free at around the >>>>>>>> same time. >>>>>>>> >>>>>>>> Have you considered "buf == null" to mean that the resources are >>>>>>>> freed? That might avoid needing to change the serialized form. Also as >>>>>>>> these types are serializable it means you have to consider the case >>>>>>>> where you deserialize to buf == null && isFree == false for example. >>>>>>>> On that point, it looks to me that this code needs a readObject anyway >>>>>>>> (for several reasons). >>>>>>>> >>>>>>>> A small point is that "isFree" is a odd name for a method that doesn't >>>>>>>> return a boolean. If the patch goes ahead then I think it needs a >>>>>>>> better name, ensureNotFree or requireNotFree or something like that. >>>>>>>> >>>>>>>> -Alan. >>>>>>>> >>>>>> >>>>>> >>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>> Oracle Java Engineering >>>>>> 1 Network Drive >>>>>> Burlington, MA 01803 >>>>>> lance.ander...@oracle.com >>>>>> >>>>> >>>> >>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| >>>> Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> lance.ander...@oracle.com <mailto:lance.ander...@oracle.com> >>>> >>> >> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif> >> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| >> Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> lance.ander...@oracle.com <mailto:lance.ander...@oracle.com> >> >
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
