• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

a silly question about "JDK source code"

 
Daniel Washington
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24208
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Max Rahder
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 243
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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());
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic