Newbie: Just drop it on the classpath

[James D Carroll]

I found what seems to be a good MS SQL driver call jTDS. Its open source and
on SourceForge and, as is, typical the doc is sparse. But in this case I
think the problem is mine.

They say on their site:
"Being a type 4 driver, jTDS does not need any special installation. Just
drop the jar file into your application's classpath and you're done."

Well, bully for them. But there seems to be a hundred different ways to
manage ones classpath. AND there's no way to know that when I ship something
that the destination machine will have the same classpath as mine.

Sometimes it seems maddening. And quite frankly its hampering my ability to
get Java into our company. To them having (what they think is) a nice clean
MSI package is the way to go. But having worked in a MS shop before I know
what its like to have to run "regsvr32" on a bunch of machines just to get
them to work.

First, at least on my personal machine, can I just drop this thing in my
jre/lib directory and be happy?

Second, does anyone have advice or resources regarding jar management in the
enterprise?

Thanks all.

J

 

[Ross Bamford]

I found what seems to be a good MS SQL driver call jTDS. Its open source and
on SourceForge and, as is, typical the doc is sparse. But in this case I
think the problem is mine.

They say on their site:
"Being a type 4 driver, jTDS does not need any special installation. Just
drop the jar file into your application's classpath and you're done."

Well, bully for them. But there seems to be a hundred different ways to
manage ones classpath. AND there's no way to know that when I ship something
that the destination machine will have the same classpath as mine.

My answer is always 'dont'. I've haven't set a classpath for years. Set
JAVA_HOME at most. If your app needs a specific classpath, make it fit
and write a script.

First, at least on my personal machine, can I just drop this thing in my
jre/lib directory and be happy?

Yes. Especially if you plan to use it again.

Second, does anyone have advice or resources regarding jar management in the
enterprise?

It's potentially a hell of a mess. In a development scenario tools like
Maven help, but from the app end of things the common solution is to
unjar your jars and put the classes in your app classpath. This is
perfectly fine with *most* open source stuff but you should check the
licence.

There is an Uberjar tool but again I'm not sure how useful it is in an
app scenario (it is part of classworlds).

 

[Ross Bamford]

Yes. Especially if you plan to use it again.

Although now I think more on this there is one caveat: that it will be
loaded by the boot classloader, which may matter to you in certain
circumstances...

 

[alin]

I found what seems to be a good MS SQL driver call jTDS. Its open source and
on SourceForge and, as is, typical the doc is sparse. But in this case I
think the problem is mine.

They say on their site:
"Being a type 4 driver, jTDS does not need any special installation. Just
drop the jar file into your application's classpath and you're done."

Well, bully for them. But there seems to be a hundred different ways to
manage ones classpath. AND there's no way to know that when I ship something
that the destination machine will have the same classpath as mine.

When you ship something you should either ship it with a startup script
in which you launch it AND specify the classpath (with relative paths,
so you can place all jars under a single directory) or you can ship an
executable jar and then you can specify the classpath inside its
MANIFEST.MF file (if you'll look at the jTDS jar file you'll see a
sample usage of this).

Sometimes it seems maddening. And quite frankly its hampering my ability to
get Java into our company. To them having (what they think is) a nice clean
MSI package is the way to go. But having worked in a MS shop before I know
what its like to have to run "regsvr32" on a bunch of machines just to get
them to work.

As explained above it's quite easy to distribute a piece of Java
software (and have it work too, of course). Easier than with an MSI
package, I would say. Just extract the whole bunch and it works.

First, at least on my personal machine, can I just drop this thing in my
jre/lib directory and be happy?

You could, but I'm not sure you want to do that. First of all, it will
be loaded by the bootclassloader (which in some cases could cause
problems); second it may interfere with your apps or other apps that
may come with another version of that jar file; third, as you can see,
this won't help with distributing your app.

Second, does anyone have advice or resources regarding jar management in the
enterprise?

Google could help with this. )

Alin,
The jTDS Project.

 

[Bryce]

First, at least on my personal machine, can I just drop this thing in my
jre/lib directory and be happy?

I wouldn't recommend this.

It reallyl depends on what type of application you are deploying.

Web app? Put it in your webapps WEB-INF/lib folder
Standalone app? Just invoke with the -classpath option

Second, does anyone have advice or resources regarding jar management in the
enterprise?

See above.

For standalone apps, I just create a distribution with a lib folder,
and in the root folder is a bat/sh file that contains the java command
and -classpath option

 

[Ross Bamford]

You are of course, correct. common/endorsed is where you'd put it then
I believe.

I use server/lib and global sources, but that's a preference I
suppose...

I use a bat/sh file (and any IDE is going to allow you to manage
that).

Again, if you don't mind that's fine, but I prefer not to have a
classpath set at all ordinarily, and have a properly generated path for
each project (with Maven).

It comes down to the fact I guess that I never program against the
driver, only a datasource, but then my database requirements aren't
particularly taxing...

Which is why I said I wouldn't recommend it.

Fair enough