Online Java Programming Test - Java Programming Test - Random
- This is a FREE online test. Beware of scammers who ask for money to attend this test.
- Total number of questions: 20.
- Time allotted: 30 minutes.
- Each question carries 1 mark; there are no negative marks.
- DO NOT refresh the page.
- All the best!
Marks : 2/20
Test Review : View answers and explanation for this test.
interface is a valid keyword.
Option B is wrong because although "String" is a class type in Java, "string" is not a keyword.
Option C is wrong because "Float" is a class type. The keyword for the Java primitive is float.
Option D is wrong because "unsigned" is a keyword in C/C++ but not in Java.
The private access modifier limits access to members of the same class.
Option A, B, D, and E are wrong because protected are the wrong access modifiers, and final, static, and volatile are modifiers but not access modifiers.
class Bitwise
{
public static void main(String [] args)
{
int x = 11 & 9;
int y = x ^ 3;
System.out.println( y | 12 );
}
}
The & operator produces a 1 bit when both bits are 1. The result of the & operation is 9. The ^ operator produces a 1 bit when exactly one bit is 1; the result of this operation is 10. The | operator produces a 1 bit when at least one bit is 1; the result of this operation is 14.
int I = 0;
label:
if (I < 2) {
System.out.print("I is " + I);
I++;
continue label;
}
The code will not compile because a continue statement can only occur in a looping construct. If this syntax were legal, the combination of the continue and the if statements would create a kludgey kind of loop, but the compiler will force you to write cleaner code than this.
public class Switch2
{
final static short x = 2;
public static int y = 0;
public static void main(String [] args)
{
for (int z=0; z < 3; z++)
{
switch (z)
{
case x: System.out.print("0 ");
case x-1: System.out.print("1 ");
case x-2: System.out.print("2 ");
}
}
}
}
The case expressions are all legal because x is marked final, which means the expressions can be evaluated at compile time. In the first iteration of the for loop case x-2 matches, so 2 is printed. In the second iteration, x-1 is matched so 1 and 2 are printed (remember, once a match is found all remaining statements are executed until a break statement is encountered). In the third iteration, x is matched. So 0 1 and 2 are printed.
class Exc0 extends Exception { }
class Exc1 extends Exc0 { } /* Line 2 */
public class Test
{
public static void main(String args[])
{
try
{
throw new Exc1(); /* Line 9 */
}
catch (Exc0 e0) /* Line 11 */
{
System.out.println("Ex0 caught");
}
catch (Exception e)
{
System.out.println("exception caught");
}
}
}
An exception Exc1 is thrown and is caught by the catch statement on line 11. The code is executed in this block. There is no finally block of code to execute.
A is wrong. A try statement can exist without catch, but it must have a finally statement.
B is wrong. A try statement executes a block. If a value is thrown and the try statement has one or more catch clauses that can catch it, then control will be transferred to the first such catch clause. If that catch block completes normally, then the try statement completes normally.
C is wrong. Exceptions of type Error and RuntimeException do not have to be caught, only checked exceptions (java.lang.Exception) have to be caught. However, speaking of Exceptions, Exceptions do not have to be handled in the same method as the throw statement. They can be passed to another method.
If you put a finally block after a try and its associated catch blocks, then once execution enters the try block, the code in that finally block will definitely be executed except in the following circumstances:
- An exception arising in the finally block itself.
- The death of the thread.
- The use of System.exit()
- Turning off the power to the CPU.
public class MyProgram
{
public static void throwit()
{
throw new RuntimeException();
}
public static void main(String args[])
{
try
{
System.out.println("Hello world ");
throwit();
System.out.println("Done with try block ");
}
finally
{
System.out.println("Finally executing ");
}
}
}
Once the program throws a RuntimeException (in the throwit() method) that is not caught, the finally block will be executed and the program will be terminated. If a method does not handle an exception, the finally block is executed before the exception is propagated.
/* Missing Statement ? */
public class foo
{
public static void main(String[]args)throws Exception
{
java.io.PrintWriter out = new java.io.PrintWriter();
new java.io.OutputStreamWriter(System.out,true);
out.println("Hello");
}
}
The usual method for using/importing the java packages/classes is by using an import statement at the top of your code. However it is possible to explicitly import the specific class that you want to use as you use it which is shown in the code above. The disadvantage of this however is that every time you create a new object you will have to use the class path in the case "java.io" then the class name in the long run leading to a lot more typing.
class Foo
{
class Bar{ }
}
class Test
{
public static void main (String [] args)
{
Foo f = new Foo();
/* Line 10: Missing statement ? */
}
}
Option B is correct because the syntax is correct-using both names (the enclosing class and the inner class) in the reference declaration, then using a reference to the enclosing class to invoke new on the inner class.
Option A, C and D all use incorrect syntax. A is incorrect because it doesn't use a reference to the enclosing class, and also because it includes both names in the new.
C is incorrect because it doesn't use the enclosing class name in the reference variable declaration, and because the new syntax is wrong.
D is incorrect because it doesn't use the enclosing class name in the reference variable declaration.
- notify();
- notifyAll();
- isInterrupted();
- synchronized();
- interrupt();
- wait(long msecs);
- sleep(long msecs);
- yield();
(1), (2), and (6) are correct. They are all related to the list of threads waiting on the specified object.
(3), (5), (7), and (8) are incorrect answers. The methods isInterrupted() and interrupt() are instance methods of Thread.
The methods sleep() and yield() are static methods of Thread.
D is incorrect because synchronized is a keyword and the synchronized() construct is part of the Java language.
public class SyncTest
{
public static void main (String [] args)
{
Thread t = new Thread()
{
Foo f = new Foo();
public void run()
{
f.increase(20);
}
};
t.start();
}
}
class Foo
{
private int data = 23;
public void increase(int amt)
{
int x = data;
data = x + amt;
}
}
Option D is correct because synchronizing the code that actually does the increase will protect the code from being accessed by more than one thread at a time.
Option A is incorrect because synchronizing the run() method would stop other threads from running the run() method (a bad idea) but still would not prevent other threads with other runnables from accessing the increase() method.
Option B is incorrect for virtually the same reason as A—synchronizing the code that calls the increase() method does not prevent other code from calling the increase() method.
class MyThread extends Thread
{
public static void main(String [] args)
{
MyThread t = new MyThread(); /* Line 5 */
t.run(); /* Line 6 */
}
public void run()
{
for(int i=1; i < 3; ++i)
{
System.out.print(i + "..");
}
}
}
Line 6 calls the run() method, so the run() method executes as a normal method should and it prints "1..2.."
A is incorrect because line 5 is the proper way to create an object.
B is incorrect because it is legal to call the run() method, even though this will not start a true thread of execution. The code after line 6 will not execute until the run() method is complete.
D is incorrect because the for loop only does two iterations.
class MyThread extends Thread
{
public static void main(String [] args)
{
MyThread t = new MyThread();
t.start();
System.out.print("one. ");
t.start();
System.out.print("two. ");
}
public void run()
{
System.out.print("Thread ");
}
}
When the start() method is attempted a second time on a single Thread object, the method will throw an IllegalThreadStateException (you will not need to know this exception name for the exam). Even if the thread has finished running, it is still illegal to call start() again.
class Test
{
private Demo d;
void start()
{
d = new Demo();
this.takeDemo(d); /* Line 7 */
} /* Line 8 */
void takeDemo(Demo demo)
{
demo = null;
demo = new Demo();
}
}
Option D is correct. By a process of elimination.
Option A is wrong. The variable d is a member of the Test class and is never directly set to null.
Option B is wrong. A copy of the variable d is set to null and not the actual variable d.
Option C is wrong. The variable d exists outside the start() method (it is a class member). So, when the start() method finishes the variable d still holds a reference.
class X2
{
public X2 x;
public static void main(String [] args)
{
X2 x2 = new X2(); /* Line 6 */
X2 x3 = new X2(); /* Line 7 */
x2.x = x3;
x3.x = x2;
x2 = new X2();
x3 = x2; /* Line 11 */
doComplexStuff();
}
}
This is an example of the islands of isolated objects. By the time line 11 has run, the objects instantiated in lines 6 and 7 are referring to each other, but no live thread can reach either of them.
Option D is correct. When an object is no longer referenced, it may be reclaimed by the garbage collector. If an object declares a finalizer, the finalizer is executed before the object is reclaimed to give the object a last chance to clean up resources that would not otherwise be released. When a class is no longer needed, it may be unloaded.
Option A is wrong. I found 4 delete() methods in all of the Java class structure. They are:
- delete() - Method in class java.io.File : Deletes the file or directory denoted by this abstract pathname.
- delete(int, int) - Method in class java.lang.StringBuffer : Removes the characters in a substring of this StringBuffer.
- delete(int, int) - Method in interface javax.accessibility.AccessibleEditableText : Deletes the text between two indices
- delete(int, int) - Method in class : javax.swing.text.JTextComponent.AccessibleJTextComponent; Deletes the text between two indices
None of these destroy the object to which they belong.
Option B is wrong. I found 19 finalize() methods. The most interesting, from this questions point of view, was the finalize() method in class java.lang.Object which is called by the garbage collector on an object when garbage collection determines that there are no more references to the object. This method does not destroy the object to which it belongs.
Option C is wrong. But it is interesting. The Runtime class has many methods, two of which are:
- getRuntime() - Returns the runtime object associated with the current Java application.
- gc() - Runs the garbage collector. Calling this method suggests that the Java virtual machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the virtual machine has made its best effort to recycle all discarded objects. Interesting as this is, it doesn't destroy the object.
public class X
{
public static void main(String [] args)
{
X x = new X();
X x2 = m1(x); /* Line 6 */
X x4 = new X();
x2 = x4; /* Line 8 */
doComplexStuff();
}
static X m1(X mx)
{
mx = new X();
return mx;
}
}
By the time line 8 has run, the only object without a reference is the one generated as a result of line 6. Remember that "Java is pass by value," so the reference variable x is not affected by the m1() method.
Ref: http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html
All objects are placed in the garbage collectible heap.
Option A is incorrect because the garbage collector makes no guarantees.
Option B is incorrect because islands of isolated objects can exist.
Option C is incorrect because finalize() has no such mystical powers.
Option A is correct. The assertion status can be set for a named top-level class and any nested classes contained therein. This setting takes precedence over the class loader's default assertion status, and over any applicable per-package default. If the named class is not a top-level class, the change of status will have no effect on the actual assertion status of any class.
Option B is wrong. Is there such a thing as conditional compilation in Java?
Option C is wrong. For private methods - yes. But do not use assertions to check the parameters of a public method. An assert is inappropriate in public methods because the method guarantees that it will always enforce the argument checks. A public method must check its arguments whether or not assertions are enabled. Further, the assert construct does not throw an exception of the specified type. It can throw only an AssertionError.
Option D is wrong. Because you're never supposed to handle an assertion failure. That means don't catch it with a catch clause and attempt to recover.