Java Core Classes and Threads

In Java's Thread class, suspend(), resume(), and stop() are final methods and therefore cannot be overridden by subclasses. These methods are also deprecated in modern Java. The destroy() method is not final, so it can technically be overridden, though it's also deprecated.

In Java, threads acquire locks at the object level using intrinsic locks (monitor locks). Each object has an associated monitor that threads can lock or unlock. Threads do not lock heap memory, classes themselves, or individual variables - they lock objects to achieve synchronization.

The wait(), notify(), and notifyAll() methods must be called from within a synchronized context (i.e., while holding the object's lock). Invoking these methods without acquiring the lock results in IllegalMonitorStateException at runtime.

Invoking the notify() method wakes up a single thread waiting on the object's monitor, but it does not immediately relinquish the object lock. The lock is only released when the synchronized block or method execution finishes by the current thread.

sleep() and activeCount() are static methods of the Thread class - you call them directly on Thread.sleep() or Thread.activeCount(). join() is an instance method that you call on a specific thread object. 'none' is incorrect since join() is indeed not static.

wait(), notify(), and notifyAll() are defined in the Object class, not the Thread class - they're available on every object in Java for inter-thread communication. start() IS a method of Thread class that begins execution.

Thread defines three priority constants: MAX_PRIORITY (10), MIN_PRIORITY (1), and NORM_PRIORITY (5). LOW_PRIORITY doesn't exist - it's a distractor mixing 'LOW' with the correct constant name MIN_PRIORITY.

Black list validation is weak because attackers can bypass it using various character encoding techniques (URL encoding, Unicode, double encoding, etc.) to represent blocked characters in ways the filter doesn't recognize. Being hard-coded (A) doesn't make it weak. POST method handling (C) isn't specifically problematic for black lists. Black lists don't match good patterns (D) - they block bad ones.

Java is generally faster than JavaScript for heavy processing due to its compiled nature, static typing, and optimized JVM. JavaScript is interpreted and dynamically typed, which introduces runtime overhead. For computationally intensive tasks, Java's performance advantages are significant.

Caching frequently accessed object properties in local variables reduces repeated property lookups, which improves performance. Each property access requires the JavaScript engine to traverse the object's prototype chain. Storing the value in a local variable eliminates this overhead, especially in loops.

Given x=10 (so x*x=100), option A evaluates both conditions (100<1000 is true, must check y), and option D evaluates both (100>1000 is false, must check y due to OR). Options B and C short-circuit without full evaluation. The question asks which are SLOWER, meaning more evaluations, so A and D are correct.

In Java, Error is a direct subclass of Throwable, not Exception. Error represents serious problems like OutOfMemoryError or StackOverflowError that applications should not attempt to catch or recover from, as they typically indicate fatal JVM-level issues. Option B is incorrect because Error and Exception are siblings under Throwable.

The dmf:checkbox uses the 'onchange' attribute for state changes, but uses 'onclick' or similar for event handling methods. The onchange attribute is for defining what happens when the checkbox state changes, not the action handling method itself.

The NavigableMap interface does have a lastEntry() method, so this is not a compile error. However, calling lastEntry() on an empty ConcurrentSkipListMap returns null, not a NullPointerException. The code compiles and runs, outputting null. Option B is correct.

The floorKey(k) method returns the greatest key less than or equal to k. The map contains keys 1,2,4,5,6 (sorted order). floorKey(3) looks for the largest key <= 3, which is 2. The method exists in NavigableMap, so no compile error. The map has entries, so result is not null. Output is 2.