Tim B.

Dear Kevin,
As you stated, Java's 'import' looks the same as C/C++'s #include (Java does not use include). But there are a few (some might say major, some might say minor) differences.
First of all, Java's import statement doesn't include the file, as #include in C/C++ does, it just tells the compiler where to look for its class references. Therefore the import statement isn't used to import/include C-style header files in which you declare all the used functions, as the #include statement in C/C++ is used most of the time. Note that this isn't needed as, unlike C/C++, Java doesn't make a distinguishment between declaring a function and defining the function, as Java class files simply acts as both the declaration and the implementation of the object.
The second difference between Java's import statement and C/C++'s #include is that the latter statement is parsed by a preprocessor, transforming the statement into the equivalent C expressions/statements, thus actually adding the source code of the included file into the including file before compilation. Java does not have this kind of preprocessing because, in fact, you doesn't really need it.
Hope this helped,
Tim

Dear Dinesh,
Though I did not see what your question was exactly, I guess you want to know why your code doesn't compile. As you probably saw already you have two errors in your code.
The first problem is the line 'Rock r = new Rock(i);'. When you write this code in plain English, it states your create a new Rock object called 'r' and initiate it by calling the 'Rock' constructor method with a integer parameter called 'i'. The problem is though that you have not defined a 'Rock' constructor that takes an integer as parameter. You only defined a parameterless constructor. So you have to add something like the following code to solve this problem:
public Rock(int i)
{
System.out.println("Creating new Rock that weighs "
+ i + " pounds");
}
Your second problem is that you define a static method in your inner class. This is not allowed. If I were you, I'd forget about inner classes for now and not touch them until you've come to know the Java language a little bit better. Stick to writing one class per file, that way your code is a bit more simple to read and a little less complex.
Hope this helped,
Tim

Hi Priya,
When in the Java language a variable is declared 'final', it cannot be changed after initialisation. When a final variable is initialised and you attempt to assign it a new value, this will generate a compile error. Final variables are similar to constants in other programming languages.
In your example it means that the JLabel label can not be changed. It can not be assigned another JLabel object, nor can it's caption be changed.
Hope this helped,
Tim
[ May 05, 2003: Message edited by: Tim B. ]

Dear Raj,
In my humble opinion you make a good point, though I can think of two exceptions. Using getter and setter functions is in most cases a preferrable and more beautiful way to access variables of a class than declaring it public. Setting it to private instead of to protected is maybe a bit too much, but that of course depends on what you use your object for.
The first exception to your proposal is when you have an interface or class that is used to keep tracke of several constants which are used throughout your application. Then I suggest you use public (final) variables. The second reason I can think of to not use getter and setter methods is when performance and or size of the class file is a major issue. This second reason is more theoratical, but I guess you can say that accessing a variable through a method costs a (very little) bit more processing time than accessing it directly.
Just my two cents,
Tim

Dear Mike,
For as far as I can see, based on your code, I think the MoveabelObject class will compile. What you probably did is compile it and then 'run' it. When you would try to run this object you will indeed get a message much like: 'Exception in thread "main" java.lang.NoSuchMethodError: main'. This is because when you 'run' a java class, it will look for the 'main' method, which will then be executed. Your file does not contain a main method, hence the error.
What you should do is create another object, containing a 'main(String args[])' method. This method could instantiate your object and do all kinda other stuff that's required to actually show your object and let the user control it.
Greetings,
Tim
Ps. The code you posted is far from finished, atleast if you had in mind that the MovableObject is the only required file. It still contains an abstract method (draw) which you must implement, else nothing will happen.

Hi Ashish,
That's an interesting issue you came up with in your post. It probably wouldn't be that hard to extend an obfuscator with the possibility to create a text file, or some other file, in which a mapping of the renamed functions is stored. I think it would be a lot harder to also keep track of line numbers and other information. And don't forget, the information should be stored in a separate file which would have to be kept by the creators of the application.
But to be honest, if you write a good application, the problem you raise is non existant. Don't get me wrong, I'm not that ignorant that I think you can write an application with no errors, but I think you should write an application in which all possible exceptions are nicely handled. In other words, an application should never show the stacktrace you wrote down, but show a message which is atleast, even when using an obfuscator, meaningful to the user and/or the programmer.
Of course there are still the non catchable errors in Java, but good use of logging should make it always easy for a programmer to find out where something went wrong.
Just my two cents,
Tim

Hi Tom,
The java compiler treads packages names kinda like directories. Therefore, if you have declared the package of your User.java file as MyUser, you should place it in a directory MyUser. Not in a directory called User, else it will not find the file.
When the java compiler tries to compile a file, it checks the imports. Each import is checked in your classpath as a directory path to the files you import. If, for instance, you import java.util.HashMap and your classpath is C:\lib, it will look for C:\lib\java\util\HashMap.class. If you have a jar as (part of) your classpath (C:\lib\lib.jar), it looks for the file java\util\HashMap.class in the jar.
So what you need to do, for as far as I can see, is either rename the package to User, or renamed the directory to MyUser.
Greetings,
Tim

Hi Malhar Barai,
As you maybe know Java bytecode (.class and .jar files) contains much of the information stored in your Java source files, leaving your bytecode exposed to reverse engineering and decompiling. An obfuscator program removes the unrequired information, obfuscates symbol names and sometimes even mangles the control-flow of your application to confuse decompilers. All in all obfuscator programs are there to secure your code and to make it harder, if not impossible, to decompile your Java applications.
Greetings,
Tim

Hi Brian,
The error occurs because you're trying to assign a 'char' to a 'String' object. Your 'place' variable is declared as a String object, but the static 'toLowerCase()' method of the 'Character' class, returns a 'char'.
A solution to this problem might be the following lines of code:
char c = Character.toLowerCase(sentence.charAt(i)); Character cObj = new Character(c); place = cObj.toString();
Or if you like to do everything on one line:
place = (new Character(Character.toLowerCase(sentence.charAt(i))).toString();
Hope this helped you out a bit.
Greetings,
Tim
[ February 03, 2003: Message edited by: Tim B. ]

Hi C WL,
It is correct that the compiler fails to compile when you omit the package statement in the Client object. This because the package statement can be seen as the directory in which the file is stored.
So when you omit the package statement in the Client file, it thinks the directory of the file is actually the root directory. Importing chapter1.* will therefore look for a directory 'chapter1' in the same directory (/chapter1/chapter2/*) as the Client.java file. When you include the package statement, it knows the actual path to the file is '/chapter2/Client.java' and therefore will look for the 'chapter1' directory one level lower than the Client.java source file is in.
Hopefully you are able to follow the above explanation. If not, feel free to post a question for more information and I'll try to be a bit more specific then.
Greetings,
Tim