Ramki,
Please notice:
a)
asserts causes new object allocation, stackmaptable and exception table
grows.
Bytecodes for:
int value = 10;
assert false : value;
0: bipush 10
2: istore_1
3: getstatic #2; //Field $assertionsDisabled:Z
6: ifne 18
9: new #3; //class java/lang/AssertionError
12: dup
13: iload_1
14: invokespecial
#4; //Method java/lang/AssertionError."<init>":(I)V
17: athrow
b)
assert MyClass.openFile();
cause that openFile() will never be executed if assertions
is disabled.
So you have to write:
bool value = MyClass.openFile();
assert value;
c)
code below
assert false : System.err.println("False");
will not ever compile, because System.err.println is void.
so you have to write
try{
assert false : "False";
}
catch(AssertionError ex){
System.err.println(ex);
}
and then rely on C1/C2 to eliminate useless code.
** IMHO, counting all above it's better to write your own function
MyAssert doing exactly what you need rather than use build-in one.
** Sidestepping to conditional compilation - I vote for it
with both hands.
-Dmitry
On 2012-02-17 00:42, Srinivas Ramakrishna wrote:
> A Java language newbie question:
>
> Does anyone have any ballpark numbers on the cost (and its scaling) of
> peppering assert's in your Java code, but with asserts disabled (-da) ?
> In other words, is the disabled cost so vanishingly small that we need
> not think twice when using them, or should one be
> careful because the cost is non-negligible and can affect (bytecode)
> footprint or rutime performace even when switched off?
>
> thanks for any advice.
> -- ramki
--
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...
