Java assertion enabling/disabling: which statement about runtime control of assertions is true?

Difficulty: Easy

Correct Answer: With the proper use of runtime arguments, it is possible to instruct the VM to disable assertions for a certain class, and to enable assertions for a certain package, at the same time.

Explanation:


Introduction / Context:
Java allows fine-grained control of assertion checking at runtime using the -ea/-enableassertions and -da/-disableassertions switches. Understanding their scope and specificity is necessary for configuring development and production behavior.


Given Data / Assumptions:

  • Assertions are compiled into bytecode by default in modern Java compilers.
  • By default at runtime, assertions are disabled unless enabled with -ea.
  • VM switches can target packages (with “...” package name patterns) and individual classes.


Concept / Approach:
The VM applies assertion switches by specificity: per-class directives override per-package directives, which override global. This means you can mix enabling for a package and disabling for a specific class in that package (or vice versa) simultaneously.


Step-by-Step Solution:
Option A: False. If no flags are passed, assertions remain disabled by default.Option B: “Compiled by default” is broadly true, but this option is ambiguous regarding older source levels; the safer, unambiguously correct statement among the choices is C.Option C: True. Example: java -ea:com.example... -da:com.example.MyClass Main enables for the package but disables for a specific class.Option D: False as stated; it is not “ea wins over da” or vice versa globally—the more specific setting (class over package, package over global) takes precedence.


Verification / Alternative check:
Run a demo with assertions in com.example.MyClass and in other classes in com.example; combine -ea and -da as shown to observe selective behavior.


Why Other Options Are Wrong:
A misstates runtime default; D misstates precedence mechanics; B is not the best single correct choice in this set, as the question expects one answer highlighting runtime control.


Common Pitfalls:
Assuming assertions are enabled in production by default; misunderstanding that specificity, not flag order, controls final behavior.


Final Answer:
With appropriate VM switches, you can disable assertions for a specific class while enabling them for a package at the same time.

Discussion & Comments

No comments yet. Be the first to comment!
Join Discussion