[1] In JDBC, why should we first load drivers using Class.forName("some driver name"). Why SUN didnt take care of loading driver within the getConnection() method itself.If I pass driver name as a parameter to the getConnection() method.
[2] I want to understand JBDC internals.Any pointers towards it are appreciated.
With JDBC 4, you no longer need to use Class.forName(...) see here for one article explaining this:
Connection to a database requires that a suitable JDBC database driver be loaded in the client's VM. In the early days of JDBC, it was common to load a suitable driver via Class.forName(), passing in the name of the class implementing the JDBC Driver interface. The DriverManager class later offered a more flexible means of managing JDBC drivers in a client application. For a driver to become available, DriverManager's registerDriver() had to be invoked with the driver's class name. Alternatively, you could specify the drivers to load via the jdbc.drivers system property. When DriverManager initializes, it attempts to load the drivers associated with that property.
JDBC 4 adds the J2SE Service Provider mechanism as another means to specify database drivers. For this to work, driver JAR files must include the file META-INF/services/java.sql.driver. That file must contain a single line with the name of the JDBC driver's implementation of the Driver interface. Invoking getConnection() on DriverManager will load a driver so packaged, if needed. Upon loading the driver, an instance of the driver is created, and then registerDriver() is invoked to make that driver available to clients.
Have a look at Sun's JDBC link for more information on JDBC. The JDBC 4.0 Specification is relatively a nice read compared to some other specs...
There is no way for java.sql to know which class to load if you only give it the JDBC protocol name. Arguably JDBC driver jar files should be able to specify protocol name and driver class within their manifest or elsewhere under META-INF/. In my opinion, you might as well construct the driver instance yourself rather than attempting to load the class with a hardwired string or fiddly services file.
There isn't much to JDBC itself. The source is in src.zip of the JDK. DriverManager is the class with code.
Toolkit was right. Since JDBC 4.0 there is a mechanism that drivers will automatically register themselves using the J2SE Service Provider. Unfortunately not all JDBC vendors did update their drivers to do so. I also think that currently there are not that much JDBC drivers supporting JDBC 4.0. Meanwhile you will need to create an instance of a Driver to register the driver. The DriverManager will then check each registered driver if it accepts the JDBC url passed for a DriverManager.getConnection(). You can enable the driver logging to see what happens if driver were registered and the DriverManager tries to find the suitable driver. Therefore just call DriverManager.setLogStream() or DriverManager.setLogWriter() before.
This is one of the JDBC 4.0 drivers I know: http://www.inetsoftware.de/products/jdbc/mssql/merlia