aspose file tools*
The moose likes Beginning Java and the fly likes a silly question about Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "a silly question about "JDK source code"" Watch "a silly question about "JDK source code"" New topic
Author

a silly question about "JDK source code"

Daniel Washington
Ranch Hand

Joined: Oct 26, 2002
Posts: 53
ybe this is a simple question,but it confused me for a few days.Anyone could help me?
when I read the source code of JDK,such as Java.sql.statement,all the functions in this interface is empty,there are no content, so when some function of them is called ,how can the action happen?
such as:I call java.sql.statement.execute(sql),then what is the "actual source code" of execute()?or there are some code actually behind the execute(),where is it ?

thx a lot. don't shame me


IBM 141<br />IBM 285,286<br />IBM 700
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

Hi Daniel,

java,.sql.Statement is an interface. An interface is, indeed, just a list of methods. It's up to other classes to "implement" the interface by providing actual method bodies.

When you ask JDBC for a Statement object, notice that you don't say

Statement s = new Statement();

instead you ask a Connection for a new Statement like this:

Statement s = connection.createStatement();

That method createStatement() returns not an instance of Statement, really, but an instance of a class that implements the Statement interface. The real name of that class is of no importance. In fact, every JDBC driver will provide its own such class, so there will be many of them. You don't need to know or care what that name is, but if you're curious, you can always say

System.out.println(connection.createStatement().getClass().getName());

Anayway, so that's what a JDBC driver is: it's mainly a collection of classes that implement each of the interfaces in the java.sql package; those implementations know how to talk to one particular kind of database.


[Jess in Action][AskingGoodQuestions]
Max Rahder
Ranch Hand

Joined: Nov 06, 2000
Posts: 177
Just to continue Ernest Friedman-Hill's observations...

The people at Sun who created the JDBC interface had it easy. They simply described behavior. It's the people at Oracle or DB2 who had to implement the classes! At runtime, when you get your connection, that's where your vendor-specific driver provides that vendor's version of Connection. When you ask the connection to create a statement, you get the vendor's version of Statement. Etc. As always with polymorphism, your code doesn't really care what kinds of objects it has; your code only cares what those objects can do! Since the vendor's objects implement the interfaces, they are type-compatible with your variables, even though their actual class type is some vendor class you've never heard of. For kicks you might get your Connection, Statement, and ResultSet objects and run something like:
System.out.println(aConnection.getClass.getName());
Again... you don't really care *what* the objects are, but this might help solidify the concept that even though your code only contains references to the interface types, at runtime you actually have the vendor's version.
Daniel Washington
Ranch Hand

Joined: Oct 26, 2002
Posts: 53
Great thanks to Max Rahder and Ernest Friedman-Hill.
what you say really open my mind.
cool.
"At runtime, when you get your connection, that's where your vendor-specific driver provides that vendor's version of Connection. When you ask the connection to create a statement, you get the vendor's version of Statement. Etc."

Originally posted by Max Rahder:
Just to continue Ernest Friedman-Hill's observations...

The people at Sun who created the JDBC interface had it easy. They simply described behavior. It's the people at Oracle or DB2 who had to implement the classes! At runtime, when you get your connection, that's where your vendor-specific driver provides that vendor's version of Connection. When you ask the connection to create a statement, you get the vendor's version of Statement. Etc. As always with polymorphism, your code doesn't really care what kinds of objects it has; your code only cares what those objects can do! Since the vendor's objects implement the interfaces, they are type-compatible with your variables, even though their actual class type is some vendor class you've never heard of. For kicks you might get your Connection, Statement, and ResultSet objects and run something like:
System.out.println(aConnection.getClass.getName());
Again... you don't really care *what* the objects are, but this might help solidify the concept that even though your code only contains references to the interface types, at runtime you actually have the vendor's version.
Rick Portugal
Ranch Hand

Joined: Dec 17, 2002
Posts: 243
Thanks for that information! You guys are awesome.

By the way, it is:

System.out.println(aConnection.getClass().getName());

not:

System.out.println(aConnection.getClass.getName());


IBM 286, SCJP, SCWCD, EIEIO
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: a silly question about "JDK source code"
 
Similar Threads
calling start twice ...
What's the problem?
error in struts program
java 5 Vs 6
clarifications please...