• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

a silly question about "JDK source code"

 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.

 
Ranch Hand
Posts: 243
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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());
 
reply
    Bookmark Topic Watch Topic
  • New Topic