Hi everyone,

I need to ask a very generalised question about classpath.

Now i have a java class file named JTim.class

Now on the command line i run JTim like that

C:\j2sdk1.4.2\bin\java -cp .;C:\WINDOWS\Desktop\JProc\ JTim

Now do you guys see the folder in which JTim is in which is called
JProc. You see in JProc there is another folder called JProcTim

Now in the folder called JProcTim is a java class file also named
JTim.class

Now my question taking into account that to run the class JTim in the
JProc i did this

C:\j2sdk1.4\bin\java -cp .;C:\WINDOWS\Desktop\JProc\ JTim

is why does the intrepreter run the JTim class in the JProcTim folder and not the one i specified which is the JTim class in the JProc folder?

Any help is greatly appreciated

Thank You

Yours Sincerely

Richard West

Dani AI

Generated

Summary and focused diagnostics

The symptom reported by is a classic duplicate-class problem: there are two files named JTim.class (one in JProc\ and one in JProc\JProcTim\) but the JVM is loading the nested copy. correctly pushed to confirm the current directory and pointed toward the package/classpath model; the next step is to gather objective evidence about what the JVM is actually loading and why.

Quick diagnostic checklist (Windows)

cd
dir /s /b JTim.class
echo %CLASSPATH%
set CLASSPATH
java -verbose:class JTim
javap -classpath . -v JTim

What each check reveals

  • cd proves the working directory being used when java is invoked.
  • dir /s finds every JTim.class under the tree so duplicate copies are visible.
  • echo %CLASSPATH% / set CLASSPATH shows any environment classpath entries that might add unexpected folders or jars.
  • java -verbose:class JTim prints the exact jar/file the classloader uses (the decisive fact).
  • javap inspects the class bytecode for a package declaration or differing bytecode/version.

Likely causes and short remedies

  • Duplicate class files on the classpath: remove or rename the unwanted copy or reorder classpath entries so the intended directory comes first.
  • An environment CLASSPATH, a JRE extension directory, or a jar elsewhere contains the class—-verbose:class will expose that.
  • The nested JTim.class could be in a package or a jar; in that case the fully qualified name differs and the launcher may be invoking the other class. Moving classes into a named package and running with the fully qualified name (or eliminating duplicate class names) is the most robust fix—this is the same practical advice offered earlier by .

These checks will identify exactly which JTim.class the JVM loads and point to the minimal corrective action.

Recommended Answers

All 9 Replies

Where are you running the command from, in other words what is the current directory?

Logic says it should run the class in the JProc folder and not in any underlying folders unless they're part of a package you're calling.
So I assume you're actually in the JProc/JProcTim folder which would cause the class there to be used as it then has a higher priority to the one in the other folder.

Hi everyone,

Where are you running the command from, in other words what is the current directory?

The current directory is JProc

Logic says it should run the class in the JProc folder and not in any underlying folders unless they're part of a package you're calling.

No they are not part of any package

So I assume you're actually in the JProc/JProcTim folder which would cause the class there to be used as it then has a higher priority to the one in the other folder.

I am in the JProc folder and not in the JProcTim folder
but what is surprising me is why is the JTim class file in the
JProcTim folder has a higher priority

I don't know why its acting like that and its quite weird as i never experienced anything like this before and am quite dumbfounded

Any help is greatly appreciated

Yours Sincerely

Richard West

Hi,

You say you are running this code from the JProc folder. Why then include '.' in your classpath? as in this case '.' and 'C:\WINDOWS\Desktop\JProc\' will be one and the same thing. I am just wondering if this could be causing this strange problem. Try removing it.

Side Note: I hear it mentioned often in these forums that you should include '.' in your classpath. But all this does (unless you specifiy other direct paths) is force you to run your code from a specific directory every time. I never include '.' in my classpath's and it always works just fine, also this frees me to start my code from any directory I wish. Which in UNIX is best anyway especially if (like me) you need to launch your code in an automated manner, like from cron (crond).

Kate

Hi,

Side Note: I hear it mentioned often in these forums that you should include '.' in your classpath. But all this does (unless you specifiy other direct paths) is force you to run your code from a specific directory every time.

Kate

I believe you're mistaken on the use of the dot. The dot adds your current working directory to the classpath. That is all. It doesn't cause your application to run from that directory. Running your application from your current working directory forces your to run your code from that specific directory. See the difference?

Here is another explanation: .

Regards,

Nate

Hi everyone,

Kate and hooknc, after i removed the . i still got the same results and this thing is really puzzling me and the best part is still i still do not know why it is like that?

Richard West

Hi everyone,

Kate and hooknc, after i removed the . i still got the same results and this thing is really puzzling me and the best part is still i still do not know why it is like that?

By the way does anyone know the purpose of the ; when when setting the classpath?

Richard West

Please write a simple example of code that replicates your issue and then post the code and exactly how you're attempting to run your code.

It is hard to help you when you're so brief. We're not mind readers.

Hi Nate,

I understand what '.' and '..' represent. Did you not see the first line of my post:

You say you are running this code from the JProc folder. Why then include '.' in your classpath? as in this case '.' and 'C:\WINDOWS\Desktop\JProc\' will be one and the same thing

----------------------

When I say:

But all this does (unless you specifiy other direct paths) is force you to run your code from a specific directory every time

I mean exactly that. I believe you have misunderstood what I have said. I am not saying it forces the 'application' to execute from that directory, I am saying it forces 'you' to execute the application from that directory. See the difference?

Running your application from your current working directory forces your to run your code from that specific directory

Is that not what I said, just worded differently.

Kate

Hi Richard,

By the way does anyone know the purpose of the ; when when setting the classpath?

It is used as a path delimiter. Without it multiple specified paths would be parsed as one location.

For instance, to include two jars in the classpath to support your application you might do the following:

java -cp c:\lib\ojdbc14.jar;c:\lib\jmscommon.jar

Under UNIX you can use the ':' as a delimiter, as follows:

java -cp /home/kate/lib/ojdbc14.jar:/home/kate/lib/jmscommon.jar

You cannot use ':' under windows as it would get confused with the drive specifiers like 'c:\'.

----------------

Unless you have specific reasons not to, can you not put your classes into packages? This would then remove all confustion about which class the JVM should be starting.

Hope that helps.

Kate

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.