Dealing with packages UNIX

Discussion in 'Java' started by PythonAnimal@gmail.com, Nov 18, 2005.

  1. Guest

    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
    , Nov 18, 2005
    #1
    1. Advertising

  2. Roedy Green Guest

    On 18 Nov 2005 07:23:17 -0800, 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.
    Roedy Green, Nov 18, 2005
    #2
    1. Advertising

  3. Guest

    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
    , Nov 18, 2005
    #3
  4. On 2005-11-18, penned:
    > 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?


    --
    monique

    Ask smart questions, get good answers:
    http://www.catb.org/~esr/faqs/smart-questions.html
    Monique Y. Mudama, Nov 19, 2005
    #4
  5. 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
    Jon Martin Solaas, Nov 19, 2005
    #5
  6. 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
    Jon Martin Solaas, Nov 19, 2005
    #6
  7. Patrick May Guest

    Jon Martin Solaas <> 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.
    | (C++, Java, Common Lisp, Jini, CORBA, UML)
    Patrick May, Nov 19, 2005
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul  Smith
    Replies:
    0
    Views:
    717
    Paul Smith
    Nov 18, 2003
  2. paul
    Replies:
    4
    Views:
    268
    Michele Simionato
    Aug 3, 2003
  3. Chris Barker
    Replies:
    3
    Views:
    293
    Graham Dumpleton
    Apr 22, 2004
  4. David Lyon
    Replies:
    19
    Views:
    554
    David Lyon
    Apr 24, 2009
  5. Ian
    Replies:
    3
    Views:
    155
Loading...

Share This Page