Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Dealing with packages UNIX

Reply
Thread Tools

Dealing with packages UNIX

 
 
PythonAnimal@gmail.com
Guest
Posts: n/a
 
      11-18-2005
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

 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      11-18-2005
On 18 Nov 2005 07:23:17 -0800, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote, quoted or
indirectly quoted someone who said :

>it says cannot resolve symbole ClassName.


It always helps to copy/paste the exact wording. Lots gets lost in
paraphrasing.

I suspect your classpath is missing . as one of its elements.

see http://mindprod.com/jgloss/classpath.html
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
 
Reply With Quote
 
 
 
 
PythonAnimal@gmail.com
Guest
Posts: n/a
 
      11-18-2005
javax.servlet.ServletException: Servlet execution threw an exception


root cause

java.lang.NoSuchMethodError:
uploadequity3.EquityUpdater.loadFile(Ljava/io/InputStreamZ
uploadequity3.FileUploadAction.execute(FileUploadA ction.java:42)
org.apache.struts.action.RequestProcessor.processA ctionPerform(RequestProcessor.java:484)
org.apache.struts.action.RequestProcessor.process( RequestProcessor.java:274)
org.apache.struts.action.ActionServlet.process(Act ionServlet.java:1482)
org.apache.struts.action.ActionServlet.doPost(Acti onServlet.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

 
Reply With Quote
 
Monique Y. Mudama
Guest
Posts: n/a
 
      11-19-2005
On 2005-11-18, (E-Mail Removed) penned:
> javax.servlet.ServletException: Servlet execution threw an exception
>
>
> root cause
>
> java.lang.NoSuchMethodError:
> uploadequity3.EquityUpdater.loadFile(Ljava/io/InputStreamZ
> uploadequity3.FileUploadAction.execute(FileUploadA ction.java:42)
> org.apache.struts.action.RequestProcessor.processA ctionPerform(RequestProcessor.java:484)
> org.apache.struts.action.RequestProcessor.process( RequestProcessor.java:274)
> org.apache.struts.action.ActionServlet.process(Act ionServlet.java:1482)
> org.apache.struts.action.ActionServlet.doPost(Acti onServlet.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?


--
monique

Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
 
Reply With Quote
 
Jon Martin Solaas
Guest
Posts: n/a
 
      11-19-2005
(E-Mail Removed) wrote:
> 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

--
jon martin solaas

 
Reply With Quote
 
Jon Martin Solaas
Guest
Posts: n/a
 
      11-19-2005
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.

--
jon martin solaas
 
Reply With Quote
 
Patrick May
Guest
Posts: n/a
 
      11-19-2005
Jon Martin Solaas <(E-Mail Removed)> writes:
> 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

------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
(E-Mail Removed) | (C++, Java, Common Lisp, Jini, CORBA, UML)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Python Packages : A loomingproblem? packages might no longer work? (well not on your platform or python version anyway) David Lyon Python 19 04-23-2009 11:10 PM
Dealing with multiple versions of packages... Chris Barker Python 3 04-22-2004 10:42 AM
Do the javax.imageio packages replace packages in com.sun.image? Paul Smith Java 0 11-18-2003 02:58 PM
Dealing with paths (Unix question) paul Python 4 08-03-2003 08:45 PM



Advertisments