Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: "Small" Program Challenge. Date: Mon, 18 Jun 2012 13:31:47 -0700 (PDT) Organization: http://groups.google.com Lines: 123 Message-ID: References: <4fde76ce$0$287$14726298@news.sunsite.dk> <20ad5d23-f0a7-4926-9d99-b9dc0a7ea18e@googlegroups.com> NNTP-Posting-Host: 69.28.149.29 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1340051929 14210 127.0.0.1 (18 Jun 2012 20:38:49 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 18 Jun 2012 20:38:49 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.28.149.29; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Received-Bytes: 5485 Xref: csiph.com comp.lang.java.programmer:15392 On Monday, June 18, 2012 12:57:53 PM UTC-7, javax.swing.JSnarker wrote: > On 18/06/2012 3:47 PM, Lew wrote: > > Loading does not imply initialization, and in fact cannot. >=20 > Wrong. Loading and initialization go hand-in-hand. >=20 > > The JVM is forbidden to initialize a class except under specific > > circumstances, a >=20 > What? See JLS 12.4, which I cited upthread: "A class or interface type T will be initialized immediately before the fir= st occurrence of any one of the following: - 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 the field is not a constant vari= able (=A74.12.4). - T is a top level class (=A77.6), and an assert statement (=A714.10) lexic= ally nested within T (=A78.1.3) is executed. A reference to a static field (=A78.3.1.1) causes initialization of only th= e class or interface that actually declares it, even though it might be ref= erred to through the name of a subclass, a subinterface, or a class that im= plements an interface. Invocation of certain reflective methods in class Class and in package java= .lang.reflect also causes class or interface initialization. A class or interface will not be initialized under any other circumstance." >=20 > >> Exactly. It loads the specified class, as part of which that class's > >> static initializer runs. And if it's an enum, the enum elements' > >> initializers run too. > > > > Not true. Loading does not imply initialization, and in fact is forbidd= en to. >=20 > Wrong. Loading and initialization go hand-in-hand. Not according to the JLS. What authority are you using? > > The initializers only run under specific circumstances, separately from > > loading. > > > > I have cited the relevant JLS sections. >=20 > You haven't cited anything except my own post, and your quotation of=20 > *that* was a jumbled mess with some sections repeated for some reason. Again, I quoted the section I re-quoted in this post. I provided the link= =20 *and* quoted the relevant content. How can you say I didn't? > > False premise, unreliable conclusion. >=20 > On your part, Lew. >=20 > > Loading does not imply initialization. >=20 > Wrong. Loading and initialization go hand-in-hand. Except according to the JLS. > >> However, the observed behavior seems to be out of spec. The main > >> method's absence should prompt an error upon the attempt to invoke it, > > > > Indeed. >=20 > And not before. >=20 > When invoking a static method of a non-loaded class, the standard=20 > procedure always has been: >=20 > Load the class. > Initialize the class. Note - that is two steps, not one. > Invoke the method. >=20 > In particular, the spec requires that in this: >=20 > class A { > static int x; >=20 > static { x =3D 100; } >=20 > static int foo () { return x; } > } >=20 > a call to A.foo() should return 100, not 0. If it can attempt to invoke= =20 > foo before the static initializer has executed that would be violated. It can attempt to call 'foo()' before the initializer has executed. This is= =20 exactly one of the circumstances that causes the initializers to execute. Read the JLS! I have referenced and quoted the relevant section twice now. > On the other hand, it complaining that a reflective call to A.bar()=20 > can't be resolved sooner than the loading and initializing of A as part= =20 > of trying to resolve bar is equally anomalous. If it hasn't loaded and=20 I haven't seen any examples of reflection in this thread. Regardless,=20 "certain reflective methods" invoked will cause initialization. > initialized A yet, how can it be sure whether or not it has a method=20 > bar? On the other hand, if it's a non-reflective call the code calling=20 > bar won't even compile. --=20 Lew