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.
public class CommandArgsTwo
{
public static void main(String [] argh)
{
int x;
x = argh.length;
for (int y = 1; y <= x; y++)
{
System.out.print(" " + argh[y]);
}
}
}
and the command-line invocation is
> java CommandArgsTwo 1 2 3
An exception is thrown because at some point in (System.out.print(" " + argh[y]);), the value of x will be equal to y, resulting in an attempt to access an index out of bounds for the array. Remember that you can access only as far as length - 1, so loop logical tests should use x < someArray.length as opposed to x < = someArray.length.
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.
public class Outer
{
public void someOuterMethod()
{
//Line 5
}
public class Inner { }
public static void main(String[] argv)
{
Outer ot = new Outer();
//Line 10
}
}
Which of the following code fragments inserted, will allow to compile?
Option A compiles without problem.
Option B gives error - non-static variable cannot be referenced from a static context.
Option C package ot does not exist.
Option D gives error - non-static variable cannot be referenced from a static context.
class A
{
protected int method1(int a, int b)
{
return 0;
}
}
Option A is correct - because the class that extends A is just simply overriding method1.
Option B is wrong - because it can't override as there are less access privileges in the subclass method1.
Option C is wrong - because to override it, the return type needs to be an integer. The different return type means that the method is not overriding but the same argument list means that the method is not overloading. Conflict - compile time error.
Option D is wrong - because you can't override a method and make it a class method i.e. using static.
public class A
{
void A() /* Line 3 */
{
System.out.println("Class A");
}
public static void main(String[] args)
{
new A();
}
}
Option D is correct. The specification at line 3 is for a method and not a constructor and this method is never called therefore there is no output. The constructor that is called is the default constructor.
class Test
{
public static void main(String [] args)
{
Test p = new Test();
p.start();
}
void start()
{
boolean b1 = false;
boolean b2 = fix(b1);
System.out.println(b1 + " " + b2);
}
boolean fix(boolean b1)
{
b1 = true;
return b1;
}
}
The boolean b1 in the fix() method is a different boolean than the b1 in the start() method. The b1 in the start() method is not updated by the fix() method.
public void foo( boolean a, boolean b)
{
if( a )
{
System.out.println("A"); /* Line 5 */
}
else if(a && b) /* Line 7 */
{
System.out.println( "A && B");
}
else /* Line 11 */
{
if ( !b )
{
System.out.println( "notB") ;
}
else
{
System.out.println( "ELSE" ) ;
}
}
}
Option C is correct. The output is "ELSE". Only when a is false do the output lines after 11 get some chance of executing.
Option A is wrong. The output is "A". When a is true, irrespective of the value of b, only the line 5 output will be executed. The condition at line 7 will never be evaluated (when a is true it will always be trapped by the line 12 condition) therefore the output will never be "A && B".
Option B is wrong. The output is "A". When a is true, irrespective of the value of b, only the line 5 output will be executed.
Option D is wrong. The output is "notB".
int i = 1, j = -1;
switch (i)
{
case 0, 1: j = 1; /* Line 4 */
case 2: j = 2;
default: j = 0;
}
System.out.println("j = " + j);
Multi-constant case labels supported from Java 14, No compilation error and output will be j=0.
public class X
{
public static void main(String [] args)
{
try
{
badMethod();
System.out.print("A");
}
catch (RuntimeException ex) /* Line 10 */
{
System.out.print("B");
}
catch (Exception ex1)
{
System.out.print("C");
}
finally
{
System.out.print("D");
}
System.out.print("E");
}
public static void badMethod()
{
throw new RuntimeException();
}
}
A Run time exception is thrown and caught in the catch statement on line 10. All the code after the finally statement is run because the exception has been caught.
Option B is correct. A set is a collection that contains no duplicate elements. The iterator returns the elements in no particular order (unless this set is an instance of some class that provides a guarantee). A map cannot contain duplicate keys but it may contain duplicate values. List and Collection allow duplicate elements.
Option A is wrong. A map is an object that maps keys to values. A map cannot contain duplicate keys; each key can map to at most one value. The Map interface provides three collection views, which allow a map's contents to be viewed as a set of keys, collection of values, or set of key-value mappings. The order of a map is defined as the order in which the iterators on the map's collection views return their elements. Some map implementations, like the TreeMap class, make specific guarantees as to their order (ascending key order); others, like the HashMap class, do not (does not guarantee that the order will remain constant over time).
Option C is wrong. A list is an ordered collection (also known as a sequence). The user of this interface has precise control over where in the list each element is inserted. The user can access elements by their integer index (position in the list), and search for elements in the list. Unlike sets, lists typically allow duplicate elements.
Option D is wrong. A collection is also known as a sequence. The user of this interface has precise control over where in the list each element is inserted. The user can access elements by their integer index (position in the list), and search for elements in the list. Unlike sets, lists typically allow duplicate elements.
Hashtable is the only class listed that provides synchronized methods. If you need synchronization great; otherwise, use HashMap, it's faster.
public class Test
{
public static void main (String args[])
{
String str = NULL;
System.out.println(str);
}
}
Option B is correct because to set the value of a String variable to null you must use "null" and not "NULL".
- The value returned by hashcode() is used in some collection classes to help locate objects.
- The hashcode() method is required to return a positive int value.
- The hashcode() method in the String class is the one inherited from Object.
- Two new empty String objects will produce identical hashcodes.
(2) is an incorrect statement because there is no such requirement.
(3) is an incorrect statement and therefore a correct answer because the hashcode for a string is computed from the characters in the string.
class s implements Runnable
{
int x, y;
public void run()
{
for(int i = 0; i < 1000; i++)
synchronized(this)
{
x = 12;
y = 12;
}
System.out.print(x + " " + y + " ");
}
public static void main(String args[])
{
s run = new s();
Thread t1 = new Thread(run);
Thread t2 = new Thread(run);
t1.start();
t2.start();
}
}
The program will execute without any problems and print 12 12 12 12.
public class Test2
{
public static int x;
public static int foo(int y)
{
return y * 2;
}
public static void main(String [] args)
{
int z = 5;
assert z > 0; /* Line 11 */
assert z > 2: foo(z); /* Line 12 */
if ( z < 7 )
assert z > 4; /* Line 14 */
switch (z)
{
case 4: System.out.println("4 ");
case 5: System.out.println("5 ");
default: assert z < 10;
}
if ( z < 10 )
assert z > 4: z++; /* Line 22 */
System.out.println(z);
}
}
Assert statements should not cause side effects. Line 22 changes the value of z if the assert statement is false.
Option A is fine; a second expression in an assert statement is not required.
Option B is fine because it is perfectly acceptable to call a method with the second expression of an assert statement.
Option C is fine because it is proper to call an assert statement conditionally.
Option A is correct. Because assertions may be disabled, programs must not assume that the boolean expressions contained in assertions will be evaluated. Thus these expressions should be free of side effects. That is, evaluating such an expression should not affect any state that is visible after the evaluation is complete. Although it is not illegal for a boolean expression contained in an assertion to have a side effect, it is generally inappropriate, as it could cause program behaviour to vary depending on whether assertions are enabled or disabled.
Assertion checking may be disabled for increased performance. Typically, assertion checking is enabled during program development and testing and disabled for deployment.
Option B is wrong. Because you assert that something is "true". True is Boolean. So, an expression must evaluate to Boolean, not int or byte or anything else. Use the same rules for an assertion expression that you would use for a while condition.
Option C is wrong. Usually, enforcing a precondition on a public method is done by condition-checking code that you write yourself, to give you specific exceptions.
Option D is wrong. "You're never supposed to handle an assertion failure"
Not all legal uses of assertions are considered appropriate. As with so much of Java, you can abuse the intended use for assertions, despite the best efforts of Sun's Java engineers to discourage you. For example, you're never supposed to handle an assertion failure. That means don't catch it with a catch clause and attempt to recover. Legally, however, AssertionError is a subclass of Throwable, so it can be caught. But just don't do it! If you're going to try to recover from something, it should be an exception. To discourage you from trying to substitute an assertion for an exception, the AssertionError doesn't provide access to the object that generated it. All you get is the String message.
public class ObjComp
{
public static void main(String [] args )
{
int result = 0;
ObjComp oc = new ObjComp();
Object o = oc;
if (o == oc)
result = 1;
if (o != oc)
result = result + 10;
if (o.equals(oc) )
result = result + 100;
if (oc.equals(o) )
result = result + 1000;
System.out.println("result = " + result);
}
}
Even though o and oc are reference variables of different types, they are both referring to the same object. This means that == will resolve to true and that the default equals() method will also resolve to true.
String a = "newspaper";
a = a.substring(5,7);
char b = a.charAt(1);
a = a + b;
System.out.println(a);
Both substring() and charAt() methods are indexed with a zero-base, and substring() returns a String of length arg2 - arg1.
- If x and y refer to instances of different wrapper classes, then the fragment x.equals(y) will cause a compiler failure.
- If x and y refer to instances of different wrapper classes, then x == y can sometimes be true.
- If x and y are String references and if x.equals(y) is true, then x == y is true.
- If x, y, and z refer to instances of wrapper classes and x.equals(y) is true, and y.equals(z) is true, then z.equals(x) will always be true.
- If x and y are String references and x == y is true, then y.equals(x) will be true.
Statement (4) describes an example of the equals() method behaving transitively. By the way, x, y,and z will all be the same type of wrapper. Statement (5) is true because x and y are referring to the same String object.
Statement (1) is incorrect—the fragment will compile. Statement (2) is incorrect because x == y means that the two reference variables are referring to the same object. Statement (3) will only be true if x and y refer to the same String. It is possible for x and y to refer to two different String objects with the same value.