Sergey Petunin

Ranch Hand
+ Follow
since Dec 16, 2007
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by 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 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 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 resides) or specify the full qualified name foo/test/xcom/

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, while in test directory. The compiler doesn't see the file, as 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:

The output is

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:

This also won't do:

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:

if you're not in the "smart" directory, or:

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:

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:

Same goes when you try to compile 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"
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!
10 years ago
Seems like you have a file named 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.