Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > trigger static init

Reply
Thread Tools

trigger static init

 
 
Andreas Leitgeb
Guest
Posts: n/a
 
      04-11-2012
Lew <(E-Mail Removed)> wrote:
> Referencing the 'class' literal does not incur class initialization.


from JLS 12.4.1:
A class [...] T is initialized immediately before first [...]
T is a class and an instance of T is created.
T is a class and a static method declared by T is invoked.
A static field declared by T is assigned.
A static field declared by T is used [ ... and not constant ... ]
T is a top-level class, and an assert statement (§14.10) lexically
nested within T is executed.

Does using a class-literal <T.class> in "synchronized(T.class) {...}" count
in for implicitly using the monitor-field of the Class<T>-instance, or is
it strictly undefined (or defined somewhere else)?

Btw., I don't understand the point about assert. If the assert is
lexically nested in T and gets executed, then I'd have naively thought,
that one of the first two points would necessarily have happened,
anyway, before the assert could be reached. What am I missing here?

 
Reply With Quote
 
 
 
 
Joshua Cranmer
Guest
Posts: n/a
 
      04-11-2012
On 4/11/2012 7:52 AM, Andreas Leitgeb wrote:
> Lew<(E-Mail Removed)> wrote:
>> Referencing the 'class' literal does not incur class initialization.

>
> from JLS 12.4.1:
> A class [...] T is initialized immediately before first [...]
> T is a class and an instance of T is created.
> T is a class and a static method declared by T is invoked.
> A static field declared by T is assigned.
> A static field declared by T is used [ ... and not constant ... ]
> T is a top-level class, and an assert statement (§14.10) lexically
> nested within T is executed.
>
> Does using a class-literal<T.class> in "synchronized(T.class) {...}" count
> in for implicitly using the monitor-field of the Class<T>-instance, or is
> it strictly undefined (or defined somewhere else)?


So, the use of "T.class" creates an object of Class<T>, which is not
sufficient to cause T to be initialized. Some more inspection of the JLS
(and some experiments) leads me to the conclusion that a
synchronized(T.class) block can race with the initialization of T.

Experiments confirm that synchronized(T.class) does not cause
initialization of T.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
 
 
 
Andreas Leitgeb
Guest
Posts: n/a
 
      04-11-2012
Joshua Cranmer <(E-Mail Removed)> wrote:
> On 4/11/2012 7:52 AM, Andreas Leitgeb wrote:
>> Lew<(E-Mail Removed)> wrote:
>>> Referencing the 'class' literal does not incur class initialization.

>> Does using a class-literal<T.class> in "synchronized(T.class) {...}" count
>> in for implicitly using the monitor-field of the Class<T>-instance, or is
>> it strictly undefined (or defined somewhere else)?

> So, the use of "T.class" creates an object of Class<T>, which is not
> sufficient to cause T to be initialized.


Thanks for hitting my nail of misconception right on its head

> Some more inspection of the JLS
> (and some experiments) leads me to the conclusion that a
> synchronized(T.class) block can race with the initialization of T.
> Experiments confirm that synchronized(T.class) does not cause
> initialization of T.


Once I got creation of the Class<T> instance and initialization
of the class properly separated, then that is no longer a surprise

Thanks.
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-11-2012
On 04/11/2012 07:39 AM, Joshua Cranmer wrote:
> On 4/11/2012 7:52 AM, Andreas Leitgeb wrote:
>> Lew<(E-Mail Removed)> wrote:
>>> Referencing the 'class' literal does not incur class initialization.

>>
>> from JLS 12.4.1:
>> A class [...] T is initialized immediately before first [...]
>> T is a class and an instance of T is created.
>> T is a class and a static method declared by T is invoked.
>> A static field declared by T is assigned.
>> A static field declared by T is used [ ... and not constant ... ]
>> T is a top-level class, and an assert statement (§14.10) lexically
>> nested within T is executed.
>>
>> Does using a class-literal<T.class> in "synchronized(T.class) {...}" count
>> in for implicitly using the monitor-field of the Class<T>-instance, or is
>> it strictly undefined (or defined somewhere else)?

>
> So, the use of "T.class" creates an object of Class<T>, which is not
> sufficient to cause T to be initialized. Some more inspection of the JLS (and
> some experiments) leads me to the conclusion that a synchronized(T.class)
> block can race with the initialization of T.
>
> Experiments confirm that synchronized(T.class) does not cause initialization
> of T.


It used to, in contravention of the JLS.

"A class or interface will not be initialized under any other circumstance."
<http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.4.1>

It's important to note that the Java Language Specification explicitly forbids
class initialization from use of the 'class' literal. Prior to Java 5 there
was a bug that it did, which Sun fixed with version 5. This caused certain
libraries (notably Apache Commons) to break where they relied on the buggy
behavior, when run under Java 5+ under certain corner scenarios.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      04-11-2012
Patricia Shanahan <(E-Mail Removed)> wrote:
> On 4/11/2012 5:52 AM, Andreas Leitgeb wrote:
>> T is a top-level class, and an assert statement (§14.10) lexically
>> nested within T is executed.
>> Btw., I don't understand the point about assert. If the assert is
>> lexically nested in T and gets executed, then I'd have naively thought,
>> that one of the first two points would necessarily have happened,
>> anyway, before the assert could be reached. What am I missing here?

> Suppose S is a static class defined in T. I interpreted that as meaning
> that executing an assert in S would trigger initialization of T.
> Or suppose S is non-static, but the assert is in its static code.


I don't yet get it.

=== Main.java ===
public class Main {
public static void main(String[] args) {
Object foo = new Outer.Inner();
}
}
class Outer {
static {
System.out.println("Outer init");
}
public static class Inner {
static {
System.out.println("Inner init1");
assert 1==1 : "oups!";
System.out.println("Inner init2");
}
}
}
=== call ===
$ java -ea Other ;# ditto without the -ea
Inner init1
Inner init2
$ java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)
$
=== end of SSCCE ===

So, it *is* possible to run code "lexically included in Outer"
without Outer having been initialized first (which I had wrongly
believed to be impossible), but assert itself doesn't seem to
have the specified effect. I also read §14.10, but that just
affirms, that (in order to determine the Assertion-flag for the
toplevel class "Outer") "Outer" would be initialized, too.
It doesn't seem to happen, though.

 
Reply With Quote
 
Steven Simpson
Guest
Posts: n/a
 
      04-12-2012
On 11/04/12 15:04, Patricia Shanahan wrote:
> Suppose S is a static class defined in T. I interpreted that as meaning
> that executing an assert in S would trigger initialization of T.
>
> Or suppose S is non-static, but the assert is in its static code.


Can non-static S contain static code?


--
ss at comp dot lancs dot ac dot uk

 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      04-22-2012
Patricia Shanahan <(E-Mail Removed)> wrote:
> On 4/11/2012 8:30 AM, Andreas Leitgeb wrote:
>> Patricia Shanahan<(E-Mail Removed)> wrote:
>>> On 4/11/2012 5:52 AM, Andreas Leitgeb wrote:
>>>> T is a top-level class, and an assert statement (§14.10) lexically
>>>> nested within T is executed.

>> [an example that shows this point wrong]

> [another more elaborate example that shows this point wrong]


So, there seems to be a "bug", but no one seems to give a f^Hdime.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
init of class members : mem(0) vs. mem() vs. not-init at all news.aon.at C++ 11 01-29-2011 07:30 PM
Trigger function on shared module init rayuthar@gmail.com C Programming 2 04-17-2008 10:34 AM
questions about object initialization, default-init and value-init Jess C++ 4 05-04-2007 02:47 AM
Sequence Order between Page Init and User Control Init Tony Cheng ASP .Net 1 02-24-2006 01:56 PM
Compiler/Linker Error undefined reference to 'std::ios_base::Init::Init[in-charge]() clusardi2k@aol.com C++ 1 08-18-2005 07:11 PM



Advertisments