Win a copy of Microservices Testing (Live Project) this week in the Spring forum!

Dave Cryder

Greenhorn
+ Follow
since Aug 11, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dave Cryder

OK...I thinkI know what might be going on.

When import a package, you are basically telling the compiler "if you can't find what you need in this file, here is a list of places to check." If the class in the current file isn't actually using anything in the packages, it won't look for them, and it therefore won't notice that they are in need of recompiling.

Are you actually trying to declare any objects to be of the types in package BankAccount?

If this isn't what's causing it, it could be because of a problem with the classpath you are using, but that should produce a compile-time error.

Hope this helps.
17 years ago
If you are planning on building a string value one piece at a time by appending new values to it, StringBuffer is a better option than String. StringBuffer's append() method actually appends the new part to the existing value. You can "append" to a String, but actually what you are doing is throwing the old value away in favor of the new one. Garbage collection will tidy this up for you in the long run, but with StringBuffer you are not relying on that.

At least that's the way it was explained to me.
17 years ago
Maureen,

Yes. You can't reference .equals() on a reference that isn't actually referencing an object of the class.



You should check the state of the object by using "==" if there is a chance that the object wasn't initialized.

[ edited to break long line -ds ]
[ December 03, 2004: Message edited by: Dirk Schreckmann ]
17 years ago
The version information that "java -version" spat out indicates that the Java Virtual Machine you are running is older than the version of the compiler you are using. That's a little like trying to get a 5 1/4" floppy into a 3 1/2" drive. The JVM knows that it doesn't have all the facilities for running your byte code (or maybe it tried and died? ), so it's bailing out on you.
17 years ago
You are compiling with a version of the compiler that is newer than the version of your JVM. At least, I think that's what it is.
17 years ago
Maureen,

There's any number of ways you could do this. This is just one example


The object of class SomeClass would be created with printing disabled. You could call setSomeField() as often as you liked, changing the value of the field each time. When you call setPrintingStatus() with the parameter set to "true," the program will output the field to the system's output stream.

Keeping track of the object's internal state is what fields are for. Generally, it is a good idea to use methods to change field values (rather than making the fields themselves directly available by making them public).

Hope this helps!
17 years ago
The function System.out.println() does not return a value (has a type of "void"). Try this:
17 years ago
You have a semi-colon at the end of your if statement, thus terminating the statement without doing anything. The subsequent "else if" is not associated with any if statement, and an error is generated.

I absolutely <i>hate</i> when I do that.
17 years ago
Well, it's fine as long as you make it

otherwise, javac is not gonna like it.
17 years ago