Review request 8010416 Addition of Driver.deregisterDriver

Alan Bateman Alan.Bateman at oracle.com
Thu Mar 21 20:45:32 UTC 2013


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.



More information about the core-libs-dev mailing list