Sergey Petunin

First the start method invokes the run method of the Thread object, wich in turn invokes the run method of the Runnable constructor parameter.
Here the run method of the thread is overriden, so it doesn't start the Runnable's run method, only printing "A" instead.

The C option is incorrect.
All the information about generics is for compile time only, it's erased for the runtime. The method signature that's left is called erasure.
For example, for the method set(E e) in the Parent class, the erasure's going to be set(Object e).
So during runtime you're gonna have two identical methods, which were not explicitly overriden: public void set(Object e) in the Parent class and public void set(Object arg) in the Child class. This causes the name clash.
[ December 21, 2007: Message edited by: Serge Petunin ]

Because in the B.java file the B class extends the A class from already compiled file - A.class. To find the CLASS file, like I said, the classpath for the javac is needed.

you are setting classpath to . , so i think you being in xcom dir, you sould be able to use classes in xcom...

That's right, you're able to use CLASSES, not SOURCE FILES. A file B.java is a source file, classpath has nothing to do with it. For the javac compiler to find the source file, we have to either set the current directory to xcom (where B.java resides) or specify the full qualified name foo/test/xcom/B.java.

In D option we can see the standard way of specifying several directories in the classpath in Linux, using a colon ":". In Windows you use the semicolon ";" symbol. Though this option is incorrect anyway because we specify only the name of the file B.java, while in test directory. The compiler doesn't see the file, as B.java is in the xcom directory.

The method with the most concrete subclass is selected. String is a subclass of Object, and null can be cast to any class, so the String method is selected.

When you cast an integer number to a float or a double number, you can loose precision anyway. So practically float can hold any long number, but with a bigger loss of precision than double. See this example:

class a{ public static void main(String... args){ long l = 1234567891234567891L; double d = l; float f = l; System.out.printf("The original long:\t%d\n", l); System.out.printf("Casted to double:\t%f\n", d); System.out.printf("Casted to float:\t%f", f); } }

The output is
The original long:1234567891234567891 Casted to double:1234567891234567940,000000 Casted to float:1234567939550609410,000000

Thus no explicit cast is needed, but you have to remember about the loss of precision, as neither compiler nor runtime won't tell you about it.

This means that this command line won't do:
cd c:\source java com.smart.Nir
This also won't do:
cd c:\source\com\smart java com.smart.Nir
Without the classpath, java is blind It won't just add the package path to the current directory, and it won't search for the class file in the current directory, if you don't explicitly specify the "." in the classpath.

For compiling this file, if the Nir class doesn't import any additional classes, you just have to say:
javac c:\source\com\smart\Nir.java
if you're not in the "smart" directory, or:
cd c:\source\com\smart javac Nir.java
So for compiling the .java file you have to specify it's fully qualified name.

But when you try to run it with java, you have to specify a classpath and a fully qualified class name, no matter what's the current directory:
java -cp c:\source com.smart.Nir
As you can see, java adds the classpath to the package tree of the class and tries to find the file in the resulting directory, like this:
c:\source\ + com\smart\ = c:\source\com\smart |________| |________| classpath package path
Same goes when you try to compile Nir.java if it imports some additional classes. You have to specify the classpath to javac in the same way.
[ December 20, 2007: Message edited by: Serge Petunin ]

Declaring a variable as final doesn't make it a compile-time constant.

According to the Java Language Specification, compile-time constant has to be initialized with the compile-time constant expression, which means that it has to have an initializer right where it's declared.

That's why in the first case "a" is a compile-time constant, and "c" is not.

Also, according to JLS, a compile-time constant may be composed of a simple name that refers to a constant variable or a qualified name of the form TypeName.Identifier that refers to a constant variable.

So in the second case you're using s.a and s.c, where s is not a type name, it's an instance name, so those are not compile time expressions.

For all objects, including strings, the "==" operator checks the reference equality, so it returns true if the two variables refer to the same object in memory.

That's why s2 == s3 gives false: the s3 object is interned in the string pool at compile time, the s2 object is created at runtime.

Though s3 == s4 gives true, because due to the compile time optimization they refer to the same object interned in the pool of strings at compile time.
[ December 19, 2007: Message edited by: Serge Petunin ]

Looks like all you have to do is to remove or rename the file
"C:\Other Stuff\MyFirst\Excerpt from Java.Lang.Thread.java"
It's name clashes with the Thread class file name.

I think, it's no use for you to cram in the last days before the exam. Just try to brush up on the topics you think you know the worst. The best for you is to stop worrying, relax and get a good sleep in the night before the exam.
Looks like you're in pretty good shape. You'll manage it.
Good luck!

Seems like you have a file named Thread.java somewhere on your classpath. It's name conflicts with the java.lang.Thread which is implicitly imported in every Java class.

A is wrong, because using wait, notify and notifyAll methods while not in synchronized code causes a runtime exception IllegalMonitorStateException, not a compiler error.
B is wrong, because if no threads are waiting, calling notify will not produce any exceptions.
C and F is wrong, because the actual behavior of the thread scheduler is undefined by the Java specification, it's platform-specific. On Windows, for example, the C statement is not true.
D is true. "Enabled for running" means "in the ready-to-run state".
E is false, because yield is a static method, and it affects the currently executing thread, moving it to the "ready-to-run" state, not in "sleep" state.
[ December 19, 2007: Message edited by: Serge Petunin ]

When you assign an object of type Moof to the Object o, you don't really change the type of the actual object, you change just the type of a variable that refers to it. The real type of the object remains the same. The ability to refer to the subclass object using a superclass variable is the essense of polymorphism.

But how to define the real type of the object to which the "o" variable is referring? That's where you use the instanceof operator. During runtime, it checks that the actual type of the object is Moof, and as it is, the operator returns true.