Assertions in static blocks ?

Ulf Zibis Ulf.Zibis at
Tue Mar 9 15:04:57 PST 2010

Am 09.03.2010 23:18, schrieb David Holmes - Sun Microsystems:
> In that case it can't. And as I said previously the special case where 
> a class consists only of these constant fields (initialized by 
> compile-time constant expressions) but still has a static initializer, 
> could be a case where javac issued a warning.

Again much thanks. I guess, we are now synchronized.

> If you feel this strongly about it just file an RFE or prepare a fix.

Bug Id: 6932842

Prepare fix: This is atroublesome story. I have posted some fixes on since months, without "progress" from Sun side.



> Cheers,
> David Holmes
>>>> If (1) could never be reached, there should be a warning, in 
>>>> particular for less experienced programmers, E.g.:
>>>> "static initializer will never be triggered by any member or method 
>>>> of this class. Could only be invoked by loading the class 
>>>> explicitly or inherently(not sure)"
>>> No that doesn't make sense. A classes own methods/members are not 
>>> the trigger for classloading and/or initialization. It is the use of 
>>> those methods/members by other classes that triggers the 
>>> loading/initialization of the class containing the method/member.
>> Sorry for the bad wording, I meant "... triggered by access to any 
>> member or method of this class. ..."
>> or "There are no members or methods which could trigger the static 
>> initializer to run, so it may be never reached. ..."
>>>>> A static initializer is no different to a method or constructor in 
>>>>> that regard: none of them are ever flagged as unreachable because 
>>>>> that can't be determined a-priori by javac.
>>>> IMHO there is a _big_ difference on normal constructors and methods:
>>>> 1. They _can_ always be executed by normal java instruction.
>>>> 2. They will _never_ be executed, if not explicitly called from code.
>>>> On static initializers it's quite different:
>>>> 1. They _cannot_ be executed by normal java instruction.
>>>> 2. They will _mostly_ be _automatically_ executed but not ever, if 
>>>> a member/method from it's class is called
>>> The implicit vs explicit nature of the execution doesn't change the 
>>> fact that to determine if either is executed you need to look at the 
>>> whole program - not just the class(es) being compiled.
>> Yes, but I can't imagine any other trigger than meant under (2).
>> Hope, that I'm bothering too much,
>> -Ulf

More information about the compiler-dev mailing list