On 21/03/2013 13:36, Lance Andersen - Oracle wrote:
Need a reviewer for 8010416, addition of Driver.deregisterDriver.
The webrev can be found at
http://cr.openjdk.java.net/~lancea/8010416/webrev.00/.
If I read this correctly then the intention is that the Driver is
notified and so that it gets a chance to clean-up when
DriverManager.deregisterDriver is called to deregister it. I can see
that being useful but I don't think I understand what "releases any
resources" means. Does it means that the Driver can no longer be used or
does it mean that it should only release resources associated with its
registration with the driver manager? I think this is distinction is
important because the former means that that Driver might need to extend
AutoCloseable and define the behavior for the case that its methods are
invoked after it has been closed. In addition, I think the default
method isn't giving you the complete solution because existing drivers
will continue to "work" after their deregisterDriver is invoked.
The other concern is that Driver.deregisterDriver can be invoked
directly and this makes it possible for DriverManager to hand out
Drivers that have their resources released and I don't think this is the
intention.
I'm also concerned about the default method specifying the
SecurityException as that requires all drivers to implement this.
Ideally the permission check is in one place, DriverManager.
So overall I think this one will require a bit more consideration. One
idea to try is to create AbstractDriver with a protected deregister
method that is a no-op. Drivers would extend this if they have clean-up
to do. There may be other solutions, this is just one to try but would
force Drivers to extend this instead of implementing Driver direction.
There may be other ideas to try too (I just mention this one). The main
thing is that all the implications are understood as I think this is a
tricky one to get right.
-Alan.
