On Jan 13, 2013, at 4:25 PM, Ulf Zibis wrote: > > Am 13.01.2013 21:08, schrieb Alan Bateman: >> Assuming CCE is long standing behavior then it would be good to update the >> spec of all the other read* methods too. Alternatively a statement in the >> class description to cover it.
Yes that is my plan. > > Only using a generified version of readObject(), a CCE would be less > surprisingly to the user. The other methods then could be deprecated. Deprecation is not needed here, especially the compiler warnings. > >> >> One other thing is that the CCE has a side-effect in that it "consumes" the >> next attribute. The methods could be changed to peek at the next attribute >> but that wouldn't work without synchronization or making it clear in the >> spec that the it is not a thread-safe implementation of SQLInput. I really want to keep the changes to the bare minimum here as this and the other serial classes are hardly, if ever used at all. > > Maybe we could add a move-back method, so the stream-like behaviour would be > more clear. > Was this API ever thread-safe? No, this code has not changed since it was written by the original authors in 2003 .and it was expected the user would deal with thread safety if required. > Does it make any sense to use it multi-threaded? Not worth the time given the rarity of this class being used. There are other other areas that are more important to spend time on . I do not see a need to spend a lot of cycles on something that is barely used unless someone in the community wants take it on as activity. This can be something that can be revisited once we get past the Java SE 8 hump Best Lance > > -Ulf >
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
