Dealing with packages UNIX

P

PythonAnimal

I have a problem i have all my .java files in a uploadEquity folder.
All files have a
package uploadEquity;
When I compile a javac *.java Everything compiles. But when I do one
file on its own it says cannot resolve symbole ClassName. Everything
has the same package name in teh same directory. ALso when my web app
runs it is using an older version of the class file taht wont compile
even afer I did a rm *.class and replaced them with the javac *.java.
I am baffled by this problem, spending the last day or two trying all
sorts of things, moving folders, changing packages.
Please any help would be greatly appreciated.
Thank-you
 
P

PythonAnimal

javax.servlet.ServletException: Servlet execution threw an exception


root cause

java.lang.NoSuchMethodError:
uploadequity3.EquityUpdater.loadFile(Ljava/io/InputStream;)Z
uploadequity3.FileUploadAction.execute(FileUploadAction.java:42)
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)

Here is the error, I will recheck my class path, it seems to be taking
an older version of the EquityUpdater, could it be its looking in
another class path before it looks at mine and is using that class
file??
Thank-you
 
M

Monique Y. Mudama

javax.servlet.ServletException: Servlet execution threw an exception


root cause

java.lang.NoSuchMethodError:
uploadequity3.EquityUpdater.loadFile(Ljava/io/InputStream;)Z
uploadequity3.FileUploadAction.execute(FileUploadAction.java:42)
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
javax.servlet.http.HttpServlet.service(HttpServlet.java:856)

Here is the error, I will recheck my class path, it seems to be
taking an older version of the EquityUpdater, could it be its
looking in another class path before it looks at mine and is using
that class file?? Thank-you

Okay, in your previous post, you said the problem was:

"When I compile a javac *.java Everything compiles. But when I do one
file on its own it says cannot resolve symbole ClassName."

Could you please explain to me how you determined that this was the
problem when the error you described above doesn't even have the
word "ClassName" in it?
 
J

Jon Martin Solaas

I have a problem i have all my .java files in a uploadEquity folder.
All files have a
package uploadEquity;
When I compile a javac *.java Everything compiles. But when I do one
file on its own it says cannot resolve symbole ClassName. Everything
has the same package name in teh same directory. ALso when my web app
runs it is using an older version of the class file taht wont compile
even afer I did a rm *.class and replaced them with the javac *.java.
I am baffled by this problem, spending the last day or two trying all
sorts of things, moving folders, changing packages.
Please any help would be greatly appreciated.
Thank-you

Suppose you have two classes; Main and Util. Main uses some method or
variable in Util. Both sourcefiles are saved in same directory called
"mypackage", and both have package specification

package mypackage;

in the top of the source.

Now you have something like:

~/javaprojects/test/src/mypackage/Main.java
~/javaprojects/test/src/mypackage/Util.java

First you tried something like

cd ~/javaprojects/test/src/mypackage/
javac *.java

This worked nicely

Then

javac Main.java

didn't work.

Now try

cd ..
javac mypackage/Main.java

Worked nicely too ...

I'm not going to attempt to explain this fully, because I can't really,
but it goes something like this:

javac needs a defined sourcepath to work. If none is provided, it'll
assume that it is the current directory, ie ./

So when you are compiling and the current directory is "mypackage" you
are really confusing javac. Compiling *.java just happens to work,
supposedly because it somehow explicitly means that javac will consider
all java files in the current directory and then it is able to figure
everything out because of the package statements in the actual source
files or something.

But when you compile just Main.java this is what happens.

1. javac supposes that classpath is ./, ie.
~/javaprojects/test/src/mypackage

2. javac can find Main.java and opens the file.

3. javac finds that Main.java somehow needs the class Util. Since
Main.java resides in the package mypackage, javac assumes Util also
does, because no explicit import statement for Util was found in Main.

4. javac starts to look for Util in package mypackage along classpath
and sourcepath. As per sourcepath javac would expect to find Util.java
in ~/javaprojects/test/src/mypackage/mypackage actually, because the
sourcepath is ~/javaprojects/test/src/mypackage/, or ./ if you will
(current directory), and because javac already has deduced that Util
must live in the same package as Main, ie. mypackage, it will look for
that file in a subdirectory called mypackage residing under the current
sourcepath, which already is .../mypackage, and it won't find it.

5. As for classpath I assume just the same happens (4).

Now, for the final exercice:

As you already have successfully compiled both classes, you also have a
Util.class file along with Util.java (and Main.java).

cd back to ~/javaprojects/test/src/mypackage

Now, we're going to tell javac exactly where to start to look for class
files (specify classpath), ie compiled sources.

javac -cp ../ Main.java

voila, this time javac will find Main.java, just like before, and deduce
the need for the class Util. It'll like before try to find Util.class in
a package called mypackage, but now it'll start looking in

~/javaprojects/test/src/

it'll append mypackage directory to~/javaprojects/test/src/ because it
assumes Util to live in the package mypackage as per the same deducement
as prevously, and hence find

~/javaprojects/test/src/mypackage/Util.class.

Now try

javac -sourcepath ../ Main.java

This also works. I'm not sure what the difference really is. What I
really am confused about is that if I delete Util.class, so that only
sourcefile Util.java is available, it still works to compile like this

cd ~/javaprojects/test/src/mypackage
javac -cp ../ Main.java

Without the -cp it'd naturally fail, that we have seen. So javac seems
to find a sourcefile along classpath and compiles it, ie. classpath
seems to work somewhat like a sourcepath?

Oh, well, I've programmed java for years now and I really don't worry
about this, I just use some Ide and pretend inconsistencies doesn't
exist rather than spending braincycles trying to figure out why it's not
inconsistent after all :)
 
J

Jon Martin Solaas

PS,

get yourself an IDE instead of struggeling with this from the command
line. You have to know how classpath and sourcepath works, BASICALLY,
but you *will* survive if you just understand the basics and let an IDE
do all the hard thinking for you.

Try: JDeveloper from Oracle, Netbeans or Eclipse. All free, and the two
latest opensource as well.
 
P

Patrick May

Jon Martin Solaas said:
get yourself an IDE instead of struggeling with this from the
command line. You have to know how classpath and sourcepath works,
BASICALLY, but you *will* survive if you just understand the basics
and let an IDE do all the hard thinking for you.

This might become the new vi/emacs war. I would argue that it is
important to understand what is going on behind the IDE interface if
one wants to become a competent software developer. Tools should be
used to automate repetitive or error-prone tasks. They should help
manage complexity, not conceal it.

Without the knowledge of classpath and dependency issues with
which the original poster is struggling, use of an IDE will lead to a
poor mental model of what is actually going on, making it far more
difficult to debug the more complex problems sure to arise in the
future.

Regards,

Patrick
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,756
Messages
2,569,533
Members
45,007
Latest member
OrderFitnessKetoCapsules

Latest Threads

Top