I'm using Text pad 4.7.3 and for some reason it is not seeing my user made class files. It was working fine last week, but when I sat down to work on it today, any class file that needs to instantiate another class file does not see the other class file (I hope that made sense). I have four files in the same folder (let's call them A, B, C, and D).
I am trying to call class B from A using the following code:
class A
{
private B clsB;
//Constructor
public A()
{
clsB = new B();
} //End constructor
} //End class
Class B is compiling fine but when I try to compile class A I get the following error:
A.java: cannot find symbol
symbol: class B
location: class A
private B clsB;
^
and another just like it when I try to instantiate the class in the constructor.
I've been going over some of my old programs (starting two years ago) and they are all having the same error: A class that needs to instantiate another class does not see the other class and, therefore, cannot compile.
The SDK/JRE I have installed is version 6 update 11. I have tried uninstalling and reinstalling all the appropriate software, i.e. Text Pad, my SDK and JRE, etc.
Can someone help? Am I missing something about a recent update that would cause this error? I have tried everything I know how to do, including renaming the class files and making sure that the file name, class name, and constructor name are all the same. Please help.
Thanks in advance.
Textpad Is Not Seeing My User Made Classes
Moderators: AmigoJack, bbadmin, helios, Bob Hansen, MudGuard
- talleyrand
- Posts: 624
- Joined: Mon Jul 21, 2003 6:56 pm
- Location: Kansas City, MO, USA
- Contact:
My java-fu is from 8 years ago but I believe you needed to modify the classpath variable to include the current working directory, denoted by a single period. A semicolon is used as a path separator. At any rate, the compiler is saying it can't find the class files since it doesn't know where to look for them. Modify that variable to something like
classpath=C:\java1.2\bin\something.jar;.
Changing that can be done via right click my computer, properties, Advanced, Environmental Variables and then find your class path.
classpath=C:\java1.2\bin\something.jar;.
Changing that can be done via right click my computer, properties, Advanced, Environmental Variables and then find your class path.
I choose to fight with a sack of angry cats.
Thank you for a quick reply, but that did not fix the problem.
All of my .java files are in the same folder that the .class files are compiled into. This has always worked for text pad. Right now I have both class A and B (both of which I wrote) in the same folder. B compiles but A doesn't because it's looking for B, which is in the same folder as A.
I've been banging my head into the wall for a couple days trying to figure this one out.
Thanks in advance again.
All of my .java files are in the same folder that the .class files are compiled into. This has always worked for text pad. Right now I have both class A and B (both of which I wrote) in the same folder. B compiles but A doesn't because it's looking for B, which is in the same folder as A.
I've been banging my head into the wall for a couple days trying to figure this one out.
Thanks in advance again.
- talleyrand
- Posts: 624
- Joined: Mon Jul 21, 2003 6:56 pm
- Location: Kansas City, MO, USA
- Contact:
Right, but is the current working path part of your class path?
If A doesn't compile and it's looking for B, then it would stand to reason the compiler doesn't know to look in that folder for the class resource.
Start -> run and then type cmd or command Ugly black DOS prompt comes up. Type set | find /i "classpath"
What's that value look like?
If A doesn't compile and it's looking for B, then it would stand to reason the compiler doesn't know to look in that folder for the class resource.
Start -> run and then type cmd or command Ugly black DOS prompt comes up. Type set | find /i "classpath"
What's that value look like?
I choose to fight with a sack of angry cats.
Again, thank you.
The value I'm getting is as follows:
CLASSPATH=C:\jdk1.5\jre\lib\ext\mysql-connector-java-3.1.12-bin.jar
I'm not sure why my classpath is sending me to the connectorJ packages, but, as I said, everything was working fine and then just stopped working.
I guess you could say I only have a white belt in java-fu. And, again, any help is appreciated. This is my favorite compiling program and I'd hate to have to change to something else.
The value I'm getting is as follows:
CLASSPATH=C:\jdk1.5\jre\lib\ext\mysql-connector-java-3.1.12-bin.jar
I'm not sure why my classpath is sending me to the connectorJ packages, but, as I said, everything was working fine and then just stopped working.
I guess you could say I only have a white belt in java-fu. And, again, any help is appreciated. This is my favorite compiling program and I'd hate to have to change to something else.
- Nicholas Jordan
- Posts: 124
- Joined: Mon Dec 20, 2004 12:33 am
- Location: Central Texas ISO Latin-1
- Contact:
package
I gave up totally on trying to use packages ( Java ) under tp,
that is usually what this is. I set my build to place class files where Arachnophilia places them, and have had some improvement in the runtime finding classes but what it gets to is that Java considers forward slash + back slash + dot + directories to be pretty much the same thing.
The compiler and the runtime will try to map classes, inner classes, directories, foldernames and user home dir in pretty much a fashion that would need at the absolute least a Master's with two to three years field experience before any realistic grasp of the situation could reduce compile and run to manageable difficulty.
I just place everything in the default package ( no package statement ) but your cs prof will not let there be rest for the wicked if that is proffered as a solution. Add to that winnie mount points resoving to
( for real ) and calling into 16-bit / non-rentrant interrupt vector table and pretty much what you have is not pretty.
Nor useable.
I think the whole get-go should be re-thougt from inside to be compatible with realistic views of contemporary computer science.
Not moanin, that's just the way it is.
that is usually what this is. I set my build to place class files where Arachnophilia places them, and have had some improvement in the runtime finding classes but what it gets to is that Java considers forward slash + back slash + dot + directories to be pretty much the same thing.
The compiler and the runtime will try to map classes, inner classes, directories, foldernames and user home dir in pretty much a fashion that would need at the absolute least a Master's with two to three years field experience before any realistic grasp of the situation could reduce compile and run to manageable difficulty.
I just place everything in the default package ( no package statement ) but your cs prof will not let there be rest for the wicked if that is proffered as a solution. Add to that winnie mount points resoving to
Code: Select all
??
( for real ) and calling into 16-bit / non-rentrant interrupt vector table and pretty much what you have is not pretty.
Nor useable.
I think the whole get-go should be re-thougt from inside to be compatible with realistic views of contemporary computer science.
Not moanin, that's just the way it is.
Most likely a broken installer, that just re-sets CLASSPATH instead of appending to the existing one. Besides, there's no need to add jars in jre\lib\ext to the CLASSPATH, since they are automatically searched (see here for version 1.3, nothing changed in later releases).fahbrock wrote:Again, thank you.
The value I'm getting is as follows:
CLASSPATH=C:\jdk1.5\jre\lib\ext\mysql-connector-java-3.1.12-bin.jar
I'm not sure why my classpath is sending me to the connectorJ packages, but, as I said, everything was working fine and then just stopped working.
As talleyrand posted before you need the current directory in the classpath, so add ;. to the CLASSPATH variable. (Or delete it alltogether, to use the default value... that is just ".")
All the gory details can be found here:
How classes are found
Setting the classpath under windows
(If you ask me the java sdk should pop up a large annoying dialog pointing to those URLs on every run )