Assertions müssen nicht global für das ganze Programm gesetzt werden, sondern könne auch feiner deklariert werden, etwa für eine Klasse oder ein Paket. Mit geschickter Variation von –ea (Assertions aktivieren) und –da (Assertions desaktivieren) lässt seht gut steuern, was die Laufzeitumgebung prüfen soll.
Beispiel
Aktiviere Assertions für die Klasse com.tutego.App:
$ java -ea:com.tutego.App AppWithMain
Aktiviere Assertions für das Default-Paket (dafür stehen die drei Punkte):
$ java -ea:… AppWithMain
Aktiviere Assertions für das Paket com.tutego inklusive aller Unterpakete (auch dafür stehen drei Punkte):
$ java -ea:com.tutego… AppWithMain
Aktiviere Assertions für das Paket com.tutego inklusive aller Unterpakete, aber desaktiviere sie für die Klasse App in dem Paket com.tutego:
$ java -ea:com.tutego… -da:com.tutego.App AppWithMain
Vor der Ausführung eines Programms im Produktivbetrieb werden die darin verwendeten Assertions üblicherweise deaktiviert?
Gar nicht so einfach hier ein binäres Ja/Nein zu geben. https://stackoverflow.com/questions/17732/when-should-assertions-stay-in-production-code gibt ein paar Ideen.