Object-Oriented Programming

The J2EE (Java 2 Enterprise Edition) specification defines 9 implicit objects for use in JSP pages: request, response, pageContext, session, application, out, config, page, and exception. These objects are automatically available without explicit declaration.

Static variables are initialized at runtime when the class is first loaded, and sealed classes cannot be inherited (overridden). Thus, statements A and B are true, making 'Both A and B' correct. The finally block always executes regardless of whether an exception occurs.

In C#, using the new keyword as a method modifier explicitly hides the inherited method of the same signature from the parent class. It does not override it (which requires the override keyword) or add a reference to it.

The scope resolution operator (::) allows defining class methods separately from the class declaration by specifying ClassName::methodName(). This operator connects the function definition to its class scope, unlike stream operators which handle I/O operations.

C++ supports virtual destructors but not virtual constructors. Virtual destructors ensure proper cleanup when deleting derived objects through base pointers, while constructors cannot be virtual since they initialize the vtable itself.

A copy constructor accepts a reference to an object of its own class, typically declared as ClassName(const ClassName& obj). This allows creating new objects by copying existing ones, while simple constructors initialize without references and parameterized constructors accept different argument types.

The Direction enum is defined inside the Nav class (line 11), making it a nested enum type. To reference it from outside code (line 14 in Sprite class), you must use the full qualified name: outer class name, then inner enum name, then the enum constant. Option D shows correct syntax: 'Nav.Direction d = Nav.Direction.NORTH;' - Nav (outer class) contains Direction (enum), which contains the constant NORTH. Option A misses the Nav prefix, Option B misses Direction enum name, and Option C misses the Nav prefix entirely.

Java's varargs syntax uses three dots (...) after the type. The five fragments test different placements: 'String...a' (correct), 'String.* a' (incorrect - * is not valid), 'String... a' (correct with space), 'String[]... a' (incorrect - array and varargs don't combine this way), 'String...[] a' (incorrect syntax). Therefore, 3 fragments compile correctly: 'public static void main(String...a)', 'public static void main(String... a)', and 'public static void main(String[]... a)' is also valid varargs syntax. Actually, upon closer inspection, String[]... a is actually valid - it's varargs of String arrays. So 3 fragments compile.

The 'name' field has default (package-private) access: no public, private, or protected modifier. In Java, default access allows only classes within the same package to directly access the field. Option C correctly states 'any class in the test package' can access and modify name. Option A is wrong because classes outside the package cannot access it. Option B is wrong because other classes in the same package CAN access it (it's not private). Option D is wrong because extending the Target class alone doesn't grant access - you must be in the test package.

The problem is that Sub's no-arg constructor tries to access private field a from Super. The issue is visibility. Option C fixes it by calling this(5), which invokes the other constructor Sub(int a), which calls super(a) - the Super constructor sets a. Option D fixes it with super(5), calling Super's constructor directly. Options A and B change visibility of a to public/protected, but that alone doesn't fix the compilation error because the no-arg constructor still can't access a properly without calling a constructor chain.

All wrapper classes in Java (Integer, Boolean, Float, Short, Long, Double, Character) are public, final, and implement Serializable. Being final prevents inheritance, being public allows access from anywhere, and Serializable allows object serialization.

The question asks which statement is false. Constructors are NOT inherited in Java - each class defines its own constructors, and a subclass must explicitly call a superclass constructor using super(). The other statements are true: throw initiates exceptions, classes without modifiers have package-private access, and the listed types are Java's eight primitives.

A constructor initializes a newly created object's state, sets initial values for fields, and can invoke the superclass constructor. Options A, C, and D are incorrect: constructors don't free memory (garbage collection does), they don't import packages (import statement does that), and JVM creation happens at runtime startup, not by constructors.