Dear Sir..
Can we directly create the instance of any driver class by using the "new" operator and by this object can we call any method like getConnection() etc,will it return connection instance.
Is it necessary these all task from loading to registering the drivers all done by the help of class.forName().
Please i am very confuse ...help me..
but why ..tell me some techinacaly...please
is it possible to do ?
> but why ..tell me some techinacaly...please
>
> is it possible to do ?
Yes of course it is possible. It's just very stupid.
You do not want to hardcode the driver implementation into your class. That totally and completely defeats the point of JDBC.
So don't do that.
Excuse me Sir..this is not stupid ok
I want to know,is it work when we instantiate it and call all method like getConnection(). will it work as same as it work as well with forClass()
> Excuse me Sir..this is not stupid ok
>
Excuse me Deepak but please remove your head from your colonic cavity forthwith.
I did not say you were stupid, although I am fast reaching that conclusion, I am saying what you are asking to do is stupid. It is a VERY stupid idea to hard code drivers into your code.
The explanation as to why is to complex for you at this point because your Java knowledge is insufficent at this time.
> I want to know,is it work when we instantiate it and
> call all method like getConnection(). will it work as
> same as it work as well with forClass()
Yes.
But if you write code that does that then you are indeed very stupid yourself.
Hope you got that clearly.
Yes, you can use the driver code directly, but that would defeat the purpose of JDBC and not provide any additional advantages.
> Excuse me Sir..this is not stupid ok
If you know it's not stupid, why are you asking? It is stupid, by the way. Your code will be coupled to a particular JDBC driver, and need re-writing and re-compiling when you want to change drivers
> I want to know,is it work when we instantiate it and
> call all method like getConnection(). will it work as
> same as it work as well with forClass()
Might do. But why bother with all that?
Actualy these all questioned discussed me in interview.They want appropriated reason from me.
I couldn't say this is stupid same question i want to share with you people alo that's it.
> Actualy these all questioned discussed me in
> interview.They want appropriated reason from me.
>
> I couldn't say this is stupid same question i want to
> share with you people alo that's it.
Why not? I would have. An interview is a two-way thing, you know. It's not just some company grilling you to see if you're any good, it's both you and the company seeing if you want to work together. Any company that asks that question isn't worth bothering with IMHO because either they're stupid enough to think that's a sensible thing to do, or they're using trick questions
Mr. georgemc as you are writeing..."If you know,this is not stupid then why are you asking".what is it mean ?should we ask stupid question?tell me Sir...
> Mr. georgemc as you are writeing..."If you know,this
> is not stupid then why are you asking".what is it
> mean ?should we ask stupid question?tell me Sir...
I mean, since you don't know the answer to this question you cannot know if it's a sensible question or not
I thing is that ,Any driver class is also a java class itself.So why did we choosen different manner to work with it than rest all classes as we instantiate first to start work with it ...why? ....I think we should discuss on it.Technical discussion on it.
> I thing is that ,Any driver class is also a java
> class itself.So why did we choosen different manner
> to work with it than rest all classes as we
> instantiate first to start work with it ...why? ....I
> think we should discuss on it.Technical discussion on
> it.
So that your code does not need to be coupled to a particular JDBC driver. It's a factoring of the abstract factory design pattern, that you can configure in a variety of ways
The JDBD API is an early (and consequently rather clumsy) example of a pattern which I call the Factory/Interface pattern (not an official name).
The idea is to allow different implementations of an API where the implentation actually used doesn't need to be known at compile time. Another example of this pattern is the SAX and DOM xml parsers. JNDI is a third example.
You wouldn't normally even have the database driver library on your classpath when compiling, so you avoid referring to the concrete Driver instance as a class reference, in the FQN of the concrete driver class is likely to be part of a configuration file.
If it were being designed today I don't doubt that the implementing class names would be contained in the services directory of the jars containing them and you wouldn't need to know their names at all, all the drivers on the class path would take a look at the URL until one accepted it.
It's a nice idea, but with JDBC the actual benefits probably aren't all that great, particularly when different vendors have different flavours of SQL.
By the way. when a driver class is loaded it registers itself with the DriverManager as part of it's class initialization code (in a static initializer), so if you do create an instance the class registers itself automatically.
You can use the Driver classes directly, I've had to do this on one occasion because I was loading the Driver from a URLClassLoader and DriverManager won't deliver drivers that have a different classloader from the class that calls getConnection().
Hi Mr. -Kayaman
could you please elaborate which type benefits, will we defeat...
Hi Mr. -Kayaman
could you please elaborate which type benefits, will we defeat...
> Hi Mr. -Kayaman
>
> could you please elaborate which type benefits, will
> we defeat...
As already mentioned in this thread several times, we would lose the ability to write code that is not coupled to a particular JDBC driver
If you're going to invite a technical discussion, at least have the decency to acknowledge it
