• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

HFSJ: Can't compile second version of BeerSelect.java

 
Ranch Hand
Posts: 41
Eclipse IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,

On page 84 of "Head First Servlets & JSP", we modify the BeerSelect (which is CoffeeSelect for me) servlet so that it calls the CoffeeExpert model class. When I attempt to compile the class with the following command line:



I get an error: "src/com/example/web/CoffeeSelect.java:3: package com.example.model does not exist import com.example.model.*;"

But the package does exist because just before attempting to compile CoffeeSelect, I was able to compile CoffeeExpert under coffeeV1/src/com/example/model.

Please help, I've been trying to figure out what is wrong all day. I'm looking for a typo or something. Here is my code for CoffeeSelect and CoffeeExpert:





My only differences are that I'm using coffee instead of beer, and I'm not including the ":classes:." bit in the compile command for the servlet, as that gives me more errors. When I compiled the first version of CoffeeSelect, I used the command line prompt I noted above and it worked fine.

Thanks,

Amanda
[ August 12, 2007: Message edited by: Amanda Albert ]
 
Ranch Hand
Posts: 136
1
Netscape Opera Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think your -classpath needs additional values. I think that you need to have the directory path of "com" in your -classpath argument

in order for this package
package com.example.model;

to be found by the compiler.

e.g.



The example is assuming that coffeeV1 is the root directory on the C drive.
[ August 12, 2007: Message edited by: Red Smith ]
 
Amanda Albert
Ranch Hand
Posts: 41
Eclipse IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Red Smith:
I think that you need to have the directory path of "com" in your -classpath argument

in order for this package
package com.example.model;

to be found by the compiler.

e.g.



The example is assuming that coffeeV1 is the root directory on the C drive.



OOOOH, I finally get it! Thank you!!! Someone else had mentioned in another forum about modifying the classpath, but I didn't know what they meant (when I think of classpath, I think of the environment variable). Now I understand how the javac command provided in the book is supposed to work. The book has colons, not semicolons.

I modified your example slightly:



Since the "src" directory is under C:\myProjects\coffeeV1, I didn't think it was necessary to write it out like you did. And it worked!

I will definitely submit the colon vs. semicolon error to the authors for the errata. I think specifying "classes" in the -classpath is wrong too because based on the structure the authors outlined, we are compiling source code under the "src" directory. The "-d classes" option is what tells the compiler to put it in the "classes" directory. Am I wrong in this thinking?

Thank you so much! I can sleep more easily tonight .

Amanda
 
Red Smith
Ranch Hand
Posts: 136
1
Netscape Opera Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Amanda Albert:

The book has colons, not semicolons.

I will definitely submit the colon vs. semicolon error to the authors for the errata.



Windows uses semicolons in their PATH variable to delimit entries and Unix uses colons. I guess Sun chose to use semicolons in CLASSPATH on Windows and colons in CLASSPATH on Unix to mimic what is in PATH. The book should definitely mention that.


I modified your example slightly:



My original example was wrong in that I had the com dir in the CLASSPATH entry. Glad you got around that and got it to work.




I think specifying "classes" in the -classpath is wrong too because based on the structure the authors outlined, we are compiling source code under the "src" directory. The "-d classes" option is what tells the compiler to put it in the "classes" directory. Am I wrong in this thinking?




I think the compiler needs to look at the .class file of any classes used by the .java code it is compiling. For other than the standard Java classes provided by Sun, the compiler needs the -classpath, or the CLASSPATH environment variable,to find them (I believe it uses only one of those 2, not a combination). There is also some default search path the compiler makes (current directory and maybe more) if the -classpath and CLASSPATH are not set.

I don't think the -d option helps the compiler find input files, so you still need to specify paths to classes in the -classpath even if the -d is telling it where to place the output .class file.
[ August 12, 2007: Message edited by: Red Smith ]
 
Amanda Albert
Ranch Hand
Posts: 41
Eclipse IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Red Smith:


I think the compiler needs to look at the .class file of any classes used by the .java code it is compiling. For other than the standard Java classes provided by Sun, the compiler needs the -classpath, or the CLASSPATH environment variable,to find them (I believe it uses only one of those 2, not a combination). There is also some default search path the compiler makes (current directory and maybe more) if the -classpath and CLASSPATH are not set.

I don't think the -d option helps the compiler find input files, so you still need to specify paths to classes in the -classpath even if the -d is telling it where to place the output .class file.

[ August 12, 2007: Message edited by: Red Smith ]



Thanks for your help Red. So you're saying that if I set my CLASSPATH variables to point to the class directories of my projects, I won't need to use the -classpath option when compiling code? So my CLASSPATH could look like this (and yes, I'm using Windows):

%JAVA_HOME%;%TOMCAT_HOME%;%ANT_HOME%;C:\MyProjects\coffeeV1\classes;C:\MyProjects\webApp2\classes;

etc etc.....

Amanda
 
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Amanda Albert:


%JAVA_HOME%;%TOMCAT_HOME%;%ANT_HOME%;C:\MyProjects\coffeeV1\classes;C:\MyProjects\webApp2\classes;



Your classpath is what the compiler and the JVM use to find java classes.

You can set it up as an environment variable (CLASSPATH) or pass it to the compiler/JVM as a command line switch. If you pass it on the command line when calling java or javac, the environment variable will be ignored.

There are some pitfalls to setting this up as an environment variable; especially if you have more than one project on your machine so a lot of books, these days, teach you to pass it via the command line switch.

There is no need for any of %JAVA_HOME%;%TOMCAT_HOME%;%ANT_HOME%
to be on your classpath. None of those directories contain java classes.

If your classes are packaged (which they should be for anything but the most trivial apps), the classpath needs to point to the directory containing the package hierarchy.

For instance, for a class with a package/name us.souther.HelloWorld residing in c:\projects\helloworld, the class file would go in:
c:\projects\helloworld\us\souther
The classpath would need to point to c:\projects\helloworld becuase this is where the us.souther package resides.

If you want use classes that are packaged within a jar file, you would need to add the actual jar file to the classpath, not just the directory in which it resides.

For example, if my HelloWorld program dependend on the servlet-api.jar library that ships with Tomcat, my classpath would need to point to both my classes and the servlet-api.jar file.

c:\projects\helloworld;c:\tomcat\common\lib\servlet-api.jar
[ August 14, 2007: Message edited by: Ben Souther ]
 
Red Smith
Ranch Hand
Posts: 136
1
Netscape Opera Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Amanda Albert:

Thanks for your help Red. So you're saying that if I set my CLASSPATH variables to point to the class directories of my projects, I won't need to use the -classpath option when compiling code?



Yes, that's correct.




So my CLASSPATH could look like this (and yes, I'm using Windows):

%JAVA_HOME%;%TOMCAT_HOME%;%ANT_HOME%;C:\MyProjects\coffeeV1\classes;C:\MyProjects\webApp2\classes;

etc etc.....




The two directories you have at the end will be sufficient to compile any Java file you create, as long as all your compiled classes that aren't in packages are in those directories, and all the packages you create start in those directories.

As an example, it would be sufficient to import or use all these classes in some Java code:

c:\MyProjects\coffeeV1\Classes\MyNonpackagedClass1.class
c:\MyProjects\coffeeV1\Classes\MyNonpackagedClass2.class
c:\MyProjects\coffeeV1\Classes\package1\subpackage\PackagedClass.class
c:\MyProjects\webApp2\Classes\MyNonpackagedClass3.class
c:\MyProjects\webApp2\Classes\package2\subpackage2\PackagedClass2.class

import package1.subpackage.PackagedClass; // should find via CLASSPATH
import package2.subpackage2.PackagedClass2; // should find via CLASSPATH
MyNonPackagedClass1 temp = new MyNonPackagedClass1(); // should find via CLASSPATH

Here's the rules for setting the directories in a CLASSPATH or -classpath:

* For a .jar or .zip file that contains .class files, the class path ends with the name of the .zip or .jar file.
* For .class files in an unnamed package, the class path ends with the directory that contains the .class files.
* For .class files in a named package, the class path ends with the directory that contains the "root" package (the first package in the full package name).
 
Amanda Albert
Ranch Hand
Posts: 41
Eclipse IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Red Smith:



The two directories you have at the end will be sufficient to compile any Java file you create, as long as all your compiled classes that aren't in packages are in those directories, and all the packages you create start in those directories.



Thanks Red, I think I get it now. Based on someone else's suggestion, I'm going to continue practice with writing code in plain text editors and using the commmand line to compile and run my programs. I've become lazy with IDEs .
[ August 17, 2007: Message edited by: Amanda Albert ]
 
Amanda Albert
Ranch Hand
Posts: 41
Eclipse IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ben Souther:


You can set it up as an environment variable (CLASSPATH) or pass it to the compiler/JVM as a command line switch. If you pass it on the command line when calling java or javac, the environment variable will be ignored.

There are some pitfalls to setting this up as an environment variable; especially if you have more than one project on your machine so a lot of books, these days, teach you to pass it via the command line switch.

There is no need for any of %JAVA_HOME%;%TOMCAT_HOME%;%ANT_HOME%
to be on your classpath. None of those directories contain java classes.



Thanks again Ben.

I'm always flustered about what settings to configure whenever I need to setup a machine so I can work on my Java apps. I figured the CLASSPATH environment variable helps point the computer to a lot of places at once. I guess I also need to learn more about what environment variables do .

Amanda
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Amanda Albert:


Thanks again Ben.

I'm always flustered about what settings to configure whenever I need to setup a machine so I can work on my Java apps. I figured the CLASSPATH environment variable helps point the computer to a lot of places at once. I guess I also need to learn more about what environment variables do .

Amanda



An environment variable is nothing more than a name/value pair available to any application running in the environment.

On a Windows machine, these can be set system wide (every application on the machine has access to them), per user (any application started by Amanda has access to them), or to a particular command window (anything started by this window has access to them.)

Setting a system wide or user wide classpath environment variable can cause problems. There is a limit to how long it can be in Windows, and as mentioned earlier, different Java projects may need access to different versions of the same libraries.

HFSJ, simplifies this by having its readers enter them as a command line switch only.

I usually write a script that sets all the environment variables needed for each project.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic