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.

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.

Maureen,

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

String string1 = new String(); String string2; if (string1.equals("some value")) // this will work { . . . } if (string2.equals("some other value")) // this won't (unless string2 { // has been set to some instance // 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 ]

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.

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.

Maureen,

There's any number of ways you could do this. This is just one example
public class SomeClass { private String someField; private boolean printingEnabled; public class SomeClass() { someField = new String(""); printingEnabled = false; } public void setSomeField(String stringVal) { someField = stringVal; if (printingEnabled) System.out.println(someField); } public void setPrintingStatus(boolean printingStatus) { printingEnabled = printingStatus; } }

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!

The function System.out.println() does not return a value (has a type of "void"). Try this:
//output the conversion, as long as they both aren't zero if ( c!= 0.0 || f!= 0.0 ) { return new String("When the temperature in celcius is: "+c +" The temperature in fahrenheit is: "+f); }//end if statement else { return new String("Sorry, Invalid Data! "); }//end else statement }//end method calc

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.

Well, it's fine as long as you make it
if (groupId == null)
otherwise, javac is not gonna like it.