Why would I not use a wildcard in my classpath?

Are there any disadvantages in using Java 6 wildcards in my classpath ? e.g.

C:> set CLASSPATH=.\lib\*

I can see that where there are two jars that both contain a class with the same path then using a wildcard may lead to results that are hard to track down.

But other than that, is there anyth开发者_运维技巧ing else to be aware of?

If it's what you want to do, then do it. As long as you are aware of the consequences. Keep in mind that if anyone else has to maintain the project, they may copy a bunch of jars into that folder not realizing that they'll be linked by default. It shouldn't take them too long to see what's going on, though.

I generally try to minimize the number of jar files I use, and link them all in manually. I realize this is personal preference.

You might load undesired classes by doing so, and if there is two versions of the same library; well, kaboom.

An explicit classpath can server as a documentation of what libraries (and perhaps what versions thereof!) the application depends on.

You lose this if you use wildcards - if it's not documented elsewhere, then if someone gets a copy of the app without the lib folder (or you delete it accidentally), they'll have a very hard time tracking down all the dependencies via repeatedly running the app, looking at ClassNotFoundErrors and hoping that all libraries used sensible package names.

You are potentially giving the JVM a lot of places to search, this might give some overhead as classes are loaded - I guess a clever JVM will do this efficiently.

My first reflex was don't use env.CLASSPATH, but on second thought and while thinking about why one shouldn't do it I started likeing the idea, at least for a local development and test environment (and at least for a while)

The advantage of this approach is that you can keep a local folder with all your common libraries (log4j, dom4j, joda time, google collections, the apache commons zoo, ...). So you can compile and execute all your applications from the shell without wasting time typing long classpath arguments.

And your still free to use a -cp argument, because it replaces the global CLASSPATH setting.

I would never use it on a production system. The risk is just to high that someone changes the content of that folder or the CLASSPATH variable and my application doesn't work anymore.

So for production, no global 'CLASSPATH' and no wildcards in the classpath string.

A disadvantage of using the wildcard path in an environment like above: After a while too many projects depend upon the single library folder. You don't know the sideeffects of updating a library or deleting an old one. And for large application it might be hard to find out which libraries from the pool are really needed. You might end up adding unused libs to the product just because you're unsure if the application will run without that lib.

So my conclusion - a nice shortcut for development, testing, prototyping but risky for production. For production I'd prefer (autogenerated) classpath strings without wildcards.