I continue to get this error. Java has worked before and is a very powerful development tool. I have come to a point in my project that I am implementing a major portion of important work. This is not the time to have the JVM become unavailable. Arachnophillia works, possibly it is because of the thumb drives ~ I have noted an insistence by the os to prepend a buch of stuff and keep it out of view.
Not the thing to have happen at this important nexus.
"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."
Evidently the directory containing the PrivateFileStorage.class file is not in your classpath. You can either set the CLASSPATH environment variable, or run java with the -cp option to specify the classpath for that invocation. I usually prefer the latter, because each project may have a different classpath and I don't want CLASSPATH to become a monster listing of every conceiveable place that code may be stored..
If PrivateFileStorage has no package declaration, and if the class file is located in /foo/bar, then you can run it using
java -cp /foo/bar PrivateFileStorage
Alternately if PrivateFileStorage is in package a.b, and if the class file is located in /foo/bar/a/b, then you can run it using
java -cp /foo/bar a.b.PrivateFileStorage
If for some reason you want to use CLASSPATH instead (which you probably did once in the distant past and then forgot about), see How To Set The CLASSPATH.
"I'm not back." - Bill Harding, Twister
Joined: Sep 17, 2006
Build directory contains:
F:\dev\A(class).java F:\dev\B(class).java ( a rather long listing - truncated for posting )
With no classpath specified on the command line compiler says:
F:\dev\A.java:35: cannot find symbol symbol: class B public class A extends B copiously spewing out just about my entire build directory. All of the files for my entire project have ( in the re-design ) been cleaned of any package declarations and placed in the same folder. I ran the main() using a tool that I had used for a long time. I believe I also opened a cli window and tried it, from memory this is where I got the code snippet posted in the original post in this thread.
adding "F:\dev" to classpath using control panel gets rid of a lot of errors but now a critically needed library ( jar file in extensions directory ) is no longer visible resulting in F:\dev\M.java:114: cannot find symbol : class BoyerMooreHorspoolRaita (This extension is someting I cannot do without).
removing F:\dev from environment variables using control panel and placing it on the command line gets the same compiler error, the extensions are no longer available. My classpath using the control panel to set envirionment variables is now 167 characters long just from a temporary workaround to so that the current re-design of the entire project does not make my work idempotent. To accomplish this, I moved the re-write to a thumb-drive.
The following code compiles on hard disk:
With the F:\dev left in the command line classpath switch.
BoyerMooreHorspoolRaita is a powerful tool I got from investing a lot of work in my project, I can ( if I absolutely have to ) copy parts of the work to conventional disk and do modular development while I read about 2,300 pages of books I bought and work on this question. My goal is to be able to transport a complete build with source code on thumb-drive, as built, to the Team-Lead's machine or ftp to a Tier-1 server after I generate md5deep on the directory structure where a release is working and tested. I would then run a utility ( written as part of the project ) to provide an ECDLP public key on the Team-Lead's machine for work to proceed. The JavaOne 2003 conference provided hope for ECDLP being implemented, I do not have to use Elliptic Curve, RSA PublicKey is totally sufficient, but the need to do this using publicly studied tool suites is something that is hammered again and again in the many books I have read.
The reasons why I need this are well beyond the scope of a beginner area. I have collected dozens of powerful jar files and have begun to use them copiously now that my Java skills have improved. Java has become very popular in the undergraduate computer science lab, their work is saving my project. [ February 17, 2008: Message edited by: Nicholas Jordan ]
Joined: Jan 30, 2000
Obviously then, you need to have both "F:\dev" and [whatever directory or jar contains BoyerMooreHorspoolRaita.class] in your classpath. This is true regardless of whether you use the -cp option, or set the CLASSPATH environment variable. Either way, find out where BoyerMooreHorspoolRaita.class is located, and put that in the classpath too.
A installed optional package may additionally contain one or more shared libraries (such as .dll files) and executables. Native libraries may also be placed in jre/lib/ext/<arch> for both Windows and Solaris, where <arch> will be x86 on Windows systems.
I need to keep these isolated from classpath. I put 8.63 megabytes of jar files in C:\Program Files\Java\jdk1.5.0_12\jre\lib\ext including stringsearch-mini.jar which has a well developed and studied implementation of sometihing that I need, far beyond my skills and I need to keep my work well separated. Right at the moment I am studying Sedgewick and I had to put everything in the default package to get builds. PrivateFileStorage was one of 20+ source files I was working on> It was a temporary concepting and put a main() in it to do incremental module work under the Extreme Programming Model.
For example, just this moment as I type this - I am on line 502 of one of 32 .java files ranging from 1kb to 32kb straightening out loops and so on that you and EFH helped me with about 12-14 months ago ~ I am really slapping the code up there and have now moved back over to the HDD-0 though I should be developing this rewrite on a thumb drive that I can keep mentally separated from primary build directory. I have gone back to naming my classes something like GraceHopper so that I can keep track of is-a/has-a/does-action/is-finished in a sense that abstracts away Files, Collections, and Classes .... all of which are now tools == much of what OO wanted me to do in the first place. ( except the programming model is now effective )
Trying to disentangle whether class A extends class B or B extends A easily hangs on circular intrinsics that do not yield to hierarchical cluster analysis, but I can determine that what I put in \jdk1.5.0_12\jre\lib\ext needs to be modeled in my program concept as tools which have been developed by the strengths that the Java Programming Paradigm bring to the progress of computer science - and those tools should remain cleanly isolated from classpath issues.