Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #37437 > unrolled thread

Are Outer Classes Loaded Lazily?

Back to article view | Back to comp.lang.java.programmer

Contents

  Are Outer Classes Loaded Lazily? j4n bur53 <janburse@fastmail.fm> - 2017-09-20 19:23 +0200
    Re: Are Outer Classes Loaded Lazily? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-09-20 17:45 -0400
      Re: Are Outer Classes Loaded Lazily? j4n bur53 <janburse@fastmail.fm> - 2017-09-21 01:18 +0200
        Re: Are Outer Classes Loaded Lazily? lewbloch@gmail.com - 2017-09-20 17:28 -0700
          Re: Are Outer Classes Loaded Lazily? j4n bur53 <janburse@fastmail.fm> - 2017-09-21 09:29 +0200
            Re: Are Outer Classes Loaded Lazily? j4n bur53 <janburse@fastmail.fm> - 2017-09-21 09:40 +0200
            Re: Are Outer Classes Loaded Lazily? lewbloch@gmail.com - 2017-09-21 11:44 -0700
    Re: Are Outer Classes Loaded Lazily? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2017-09-21 21:18 +0200
      Re: Are Outer Classes Loaded Lazily? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-09-21 16:20 -0400
        Re: Are Outer Classes Loaded Lazily? j4n bur53 <janburse@fastmail.fm> - 2017-09-22 11:12 +0200
          Re: Are Outer Classes Loaded Lazily? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2017-09-22 15:55 -0400
            Re: Are Outer Classes Loaded Lazily? j4n bur53 <janburse@fastmail.fm> - 2017-09-23 18:33 +0200
      Re: Are Outer Classes Loaded Lazily? lewbloch@gmail.com - 2017-09-22 13:48 -0700
        Re: Are Outer Classes Loaded Lazily? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2017-09-22 23:46 -0400
          Re: Are Outer Classes Loaded Lazily? lewbloch@gmail.com - 2017-09-25 13:23 -0700
        Re: Are Outer Classes Loaded Lazily? j4n bur53 <janburse@fastmail.fm> - 2017-09-24 17:39 +0200
          Re: Are Outer Classes Loaded Lazily? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-09-25 07:38 -0400
          Re: Are Outer Classes Loaded Lazily? lewbloch@gmail.com - 2017-09-25 13:25 -0700

#37437 — Are Outer Classes Loaded Lazily?

Assume I have a nested inner class Inner,
and I do the following:

    Class x=Class.forName('../Outer$Inner');

And then I do the following:

    Class y=x.getEnclosingClass();

Is the enclosing class '../Outer' already
loaded during the Class.forName() or only
when I do getEnclosingClass() ?

P.S.: The inner class is without synthetics,
no access to the outer class.

[toc] | [next] | [standalone]

#37438

On 9/20/2017 1:23 PM, j4n bur53 wrote:
> Assume I have a nested inner class Inner,
> and I do the following:
> 
>     Class x=Class.forName('../Outer$Inner');

     One or two tiny little problems here ... ;)

> And then I do the following:
> 
>     Class y=x.getEnclosingClass();
> 
> Is the enclosing class '../Outer' already
> loaded during the Class.forName() or only
> when I do getEnclosingClass() ?

     You'd need to scrutinize the JLS and/or the JVMS to be
certain.  That can be difficult: They seek exactness and
sometimes find it on the other side of opacity ...

     Instead, I ran a quick experiment: I wrote suitable
Outer and Inner classes, plus a Foo class to make the
forName() and getEnclosingClass() calls sandwiched by
some System.out.println() calls, and ran it as

	java -verbose:class esosman.misc.Foo

This told me that forName() caused Inner to be loaded
but not Outer, and that getEnclosingClass() caused
Outer to be loaded but not initialized.  (I also found
that Inner was initialized during forName() if it was
made `static', but couldn't tell what happened when it
was non-`static'.)

-- 
esosman@comcast-dot-net.invalid
Twelve hundred eighteen days to go.

[toc] | [prev] | [next] | [standalone]

#37439

for nested classes the method getEnclosingClass(),
calls getDeclaringClass(), which is native. but I
guess it will use the outer_class_info_index in
the class file format.

which is a little unnecessary, since it could derive
the outer class name from the inner class name,
lastIndexOf('$') or somesuch.

but your testing somehow indicates that getDeclaringClass()
indeed works lazily. Can this be? This would imply
that it can be possible that the static of Inner

might be called before the static of Outer?

Or is this an artefact of reflection. Since in
real code we habe a name Outer.Inner and since
this mentions Outer, it would load Outer?

Eric Sosman schrieb:
> On 9/20/2017 1:23 PM, j4n bur53 wrote:
>> Assume I have a nested inner class Inner,
>> and I do the following:
>>
>>     Class x=Class.forName('../Outer$Inner');
>
>     One or two tiny little problems here ... ;)
>
>> And then I do the following:
>>
>>     Class y=x.getEnclosingClass();
>>
>> Is the enclosing class '../Outer' already
>> loaded during the Class.forName() or only
>> when I do getEnclosingClass() ?
>
>     You'd need to scrutinize the JLS and/or the JVMS to be
> certain.  That can be difficult: They seek exactness and
> sometimes find it on the other side of opacity ...
>
>     Instead, I ran a quick experiment: I wrote suitable
> Outer and Inner classes, plus a Foo class to make the
> forName() and getEnclosingClass() calls sandwiched by
> some System.out.println() calls, and ran it as
>
>     java -verbose:class esosman.misc.Foo
>
> This told me that forName() caused Inner to be loaded
> but not Outer, and that getEnclosingClass() caused
> Outer to be loaded but not initialized.  (I also found
> that Inner was initialized during forName() if it was
> made `static', but couldn't tell what happened when it
> was non-`static'.)
>

[toc] | [prev] | [next] | [standalone]

#37440

Pretty much all classes in Java are lazily loaded and lazily initialized.

Since an inner class by definition in Java is non-static, I don't know how you could get the inner class without initializing the outer, but I have yet to peruse the JLS to explore that.

For static nested classes it makes sense that getting the enclosing class would load the class, but since that's not one of the actions that initializes a class it would be improper for that to initialize the outer class.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#37442

But not all class properties. For example the super class
is loaded before the class. So this API method of Class:

      getSuperclass()

is not lazy. Now question is whether for named nested
classes, that are static (or non-static without references
to the outer class), whether this method, is lazy or not:

      getDeclaringClass()

lewbloch@gmail.com schrieb:
> Pretty much all classes in Java are lazily loaded and lazily initialized.
>
> Since an inner class by definition in Java is non-static, I don't know how you could get the inner class without initializing the outer, but I have yet to peruse the JLS to explore that.
>
> For static nested classes it makes sense that getting the enclosing class would load the class, but since that's not one of the actions that initializes a class it would be improper for that to initialize the outer class.
>

[toc] | [prev] | [next] | [standalone]

#37443

Original question was for
getEnclosingClass(), but:

     public Class<?> getEnclosingClass() throws SecurityException {
         Class.EnclosingMethodInfo var1 = this.getEnclosingMethodInfo();
         Class var2;
         if(var1 == null) {
             var2 = this.getDeclaringClass();
         [...]
     }

     public native Class<?> getDeclaringClass();

The above is OpenJDK 1.6, in OpenJDK 1.8, there is native
getDeclaringClass0() and some extra package checks.

j4n bur53 schrieb:
> But not all class properties. For example the super class
> is loaded before the class. So this API method of Class:
>
>      getSuperclass()
>
> is not lazy. Now question is whether for named nested
> classes, that are static (or non-static without references
> to the outer class), whether this method, is lazy or not:
>
>      getDeclaringClass()
>
> lewbloch@gmail.com schrieb:
>> Pretty much all classes in Java are lazily loaded and lazily initialized.
>>
>> Since an inner class by definition in Java is non-static, I don't know
>> how you could get the inner class without initializing the outer, but
>> I have yet to peruse the JLS to explore that.
>>
>> For static nested classes it makes sense that getting the enclosing
>> class would load the class, but since that's not one of the actions
>> that initializes a class it would be improper for that to initialize
>> the outer class.
>>
>

[toc] | [prev] | [next] | [standalone]

#37444

j4n bur53 wrote:
> But not all class properties. For example the super class
> is loaded before the class. So this API method of Class:
> 
>       getSuperclass()
> 
> is not lazy. Now question is whether for named nested
> classes, that are static (or non-static without references
> to the outer class), whether this method, is lazy or not:
> 
>       getDeclaringClass()

What do you mean by a method being "lazy"? The original question is whether classes are loaded (or initialized, by extension) lazily. A method being "lazy" is not a thing.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#37445

On 20.09.17 19.23, j4n bur53 wrote:
> Assume I have a nested inner class Inner,
> and I do the following:
>
>     Class x=Class.forName('../Outer$Inner');
>
> And then I do the following:
>
>     Class y=x.getEnclosingClass();
>
> Is the enclosing class '../Outer' already
> loaded during the Class.forName() or only
> when I do getEnclosingClass() ?

AFAIK there are no dependencies in static construction of class types, 
regardless whether they are inner, outer or whatever.
The only guarantee is, that a class initialization is run before any 
member access. No more, no less. So unless you create such a dependency 
you cannot assume the outer class to be initialized.

Of course, the rule "before" is also fulfilled if the outer class would 
be initialized immediately. So at the end it is implementation defined.
But I assume that it is unlikely that an implementation initializes the 
outer class earlier than required, just because this could break a 
dependency of Outer on Inner. I.e. if the initialization of the outer 
class accesses static members of Inner.


Marcel

[toc] | [prev] | [next] | [standalone]

#37446

On 9/21/2017 3:18 PM, Marcel Mueller wrote:
> On 20.09.17 19.23, j4n bur53 wrote:
>> Assume I have a nested inner class Inner,
>> and I do the following:
>>
>>     Class x=Class.forName('../Outer$Inner');
>>
>> And then I do the following:
>>
>>     Class y=x.getEnclosingClass();
>>
>> Is the enclosing class '../Outer' already
>> loaded during the Class.forName() or only
>> when I do getEnclosingClass() ?
> 
> AFAIK there are no dependencies in static construction of class types, 
> regardless whether they are inner, outer or whatever.
> The only guarantee is, that a class initialization is run before any 
> member access. No more, no less. So unless you create such a dependency 
> you cannot assume the outer class to be initialized.
> 
> Of course, the rule "before" is also fulfilled if the outer class would 
> be initialized immediately. So at the end it is implementation defined.
> But I assume that it is unlikely that an implementation initializes the 
> outer class earlier than required, just because this could break a 
> dependency of Outer on Inner. I.e. if the initialization of the outer 
> class accesses static members of Inner.

     Note that the O.P. did not ask when the classes were
initialized, but when they were loaded.  Loading is
described (briefly) in JLS 12.2, linking in 12.3, and
initialization in 12.4.  For a more comprehensive (and
harder to follow) description, see JVMS 5.3-5.5.

-- 
esosman@comcast-dot-net.invalid
Twelve hundred seventeen days to go.

[toc] | [prev] | [next] | [standalone]

#37448

Yes I am interested in loading and not in
intialization. Unfortuantely I have not yet
managed to add some good load tracing

to my app. The suggestion -verbose:class
is a command line option, but since I have
anyway a custom class loader,

maybe I can switch on/off the verbose
flag programmatically or pipe my own logging
message to somewhere, to figure out

whats going on...

Eric Sosman schrieb:
> On 9/21/2017 3:18 PM, Marcel Mueller wrote:
>> On 20.09.17 19.23, j4n bur53 wrote:
>>> Assume I have a nested inner class Inner,
>>> and I do the following:
>>>
>>>     Class x=Class.forName('../Outer$Inner');
>>>
>>> And then I do the following:
>>>
>>>     Class y=x.getEnclosingClass();
>>>
>>> Is the enclosing class '../Outer' already
>>> loaded during the Class.forName() or only
>>> when I do getEnclosingClass() ?
>>
>> AFAIK there are no dependencies in static construction of class types,
>> regardless whether they are inner, outer or whatever.
>> The only guarantee is, that a class initialization is run before any
>> member access. No more, no less. So unless you create such a
>> dependency you cannot assume the outer class to be initialized.
>>
>> Of course, the rule "before" is also fulfilled if the outer class
>> would be initialized immediately. So at the end it is implementation
>> defined.
>> But I assume that it is unlikely that an implementation initializes
>> the outer class earlier than required, just because this could break a
>> dependency of Outer on Inner. I.e. if the initialization of the outer
>> class accesses static members of Inner.
>
>     Note that the O.P. did not ask when the classes were
> initialized, but when they were loaded.  Loading is
> described (briefly) in JLS 12.2, linking in 12.3, and
> initialization in 12.4.  For a more comprehensive (and
> harder to follow) description, see JVMS 5.3-5.5.
>

[toc] | [prev] | [next] | [standalone]

#37449

On 9/22/2017 5:12 AM, j4n bur53 wrote:
> Yes I am interested in loading and not in
> intialization. Unfortuantely I have not yet
> managed to add some good load tracing
> 
> to my app. The suggestion -verbose:class
> is a command line option, but since I have
> anyway a custom class loader,
> 
> maybe I can switch on/off the verbose
> flag programmatically or pipe my own logging
> message to somewhere, to figure out
> 
> whats going on...

The JVM defines roughly 5 distinct stages of loading:
"Loading" == "find the bytes that make up this class"
"Verifying" == "make sure the bytes are a valid .class file"
"Preparing" == "allocate the backing memory for statics"
"Resolving" == "make sure that references in opcodes are legal"
"Initializing" == "call <clinit>"

The spec also uses the term "linking" as a catch-all for the latter 4 
steps, but also states that when the stages actually happen are 
flexible. Only the last step is strictly controlled by the JVM. It's 
really vague when loading may occur, but it needs to occur no later than 
the resolution step.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#37453

linking = latter 4 except init

Joshua Cranmer 🐧 schrieb:
> On 9/22/2017 5:12 AM, j4n bur53 wrote:
>> Yes I am interested in loading and not in
>> intialization. Unfortuantely I have not yet
>> managed to add some good load tracing
>>
>> to my app. The suggestion -verbose:class
>> is a command line option, but since I have
>> anyway a custom class loader,
>>
>> maybe I can switch on/off the verbose
>> flag programmatically or pipe my own logging
>> message to somewhere, to figure out
>>
>> whats going on...
>
> The JVM defines roughly 5 distinct stages of loading:
> "Loading" == "find the bytes that make up this class"
> "Verifying" == "make sure the bytes are a valid .class file"
> "Preparing" == "allocate the backing memory for statics"
> "Resolving" == "make sure that references in opcodes are legal"
> "Initializing" == "call <clinit>"
>
> The spec also uses the term "linking" as a catch-all for the latter 4
> steps, but also states that when the stages actually happen are
> flexible. Only the last step is strictly controlled by the JVM. It's
> really vague when loading may occur, but it needs to occur no later than
> the resolution step.
>

[toc] | [prev] | [next] | [standalone]

#37450

Marcel Mueller wrote:
> AFAIK there are no dependencies in static construction of class types, 
> regardless whether they are inner, outer or whatever.

There is no such thing as "static construction" of an inner class, is there?

> The only guarantee is, that a class initialization is run before any 
> member access. No more, no less. So unless you create such a dependency 
> you cannot assume the outer class to be initialized.
> 
> Of course, the rule "before" is also fulfilled if the outer class would 
> be initialized immediately. So at the end it is implementation defined.
> But I assume that it is unlikely that an implementation initializes the 
> outer class earlier than required, just because this could break a 
> dependency of Outer on Inner. I.e. if the initialization of the outer 
> class accesses static members of Inner.

Inner classes cannot have static members except for constants.
http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.1.3

Because an inner class is associated with an instance of its outer class unless declared in a static context, and that instance cannot be created without initializing the outer class, it follows that in order for an inner class to be initialized the outer class must be initialized first.

Likewise a static context won't exist unless its owning class is (being) initialized, so again an inner class cannot be initialized without the enclosing class being initialized, AIUI.

The order of loading and initialization is not "at the end ... implementation defined" but at the beginning specified by the JLS. 
http://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html 

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#37451

On 9/22/2017 4:48 PM, lewbloch@gmail.com wrote:
> The order of loading and initialization is not "at the end ... 
> implementation defined" but at the beginning specified by the JLS. 
> http://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html

Did you actually read it?

Section 12.3:
> This specification allows an implementation flexibility as to when
> linking activities (and, because of recursion, loading) take place,
> provided that the semantics of the Java programming language are
> respected, that a class or interface is completely verified and
> prepared before it is initialized, and that errors detected during
> linkage are thrown at a point in the program where some action is
> taken by the program that might require linkage to the class or
> interface involved in the error.

When *initialization* occurs is very much well-defined. When *loading* 
occurs is very much not, pretty much the only real caveat is that 
loading takes place before initialization. OP has clearly stated that 
he's interested in when loading takes place, not when initialization 
takes place.

-- 
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#37467

Joshua Cranmer 🐧 wrote:
> Lew wrote:
> > The order of loading and initialization is not "at the end ... 
> > implementation defined" but at the beginning specified by the JLS. 
> > http://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html
> 
> Did you actually read it?

Yes. Many times. What I failed to do was realize that the question focused on loading, not initialization.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#37459

And how about a nested class, can it have static
members? The doc says yes (the link gives itself
an example):

     static class NestedButNotInner{
         static int z = 5;    // OK: not an inner class
     }

My original question is not for inner classes but
for nested classes. I am currently working on a nested
module system, and I want to compare it with Java.

And closest to nested modules are nested classes,
i.e. locale classes which are not annonymous and
which are static. Please don't get distracted in
that I wrote:

Jan Burse wrote 20.09.2017 19:23:

 > Class x=Class.forName('../Outer$Inner');

I also wrote:

 > P.S.: The inner class is without synthetics,
 > no access to the outer class.

Please excuse my sloppy wording, and the use
of class name "Inner". I am only intereste in
static nested classes, whether they require
loading their parent when they are loaded

itself. Basically Eric Sosman
already answered:

 >     java -verbose:class esosman.misc.Foo
 >
 > This told me that forName() caused Inner to be loaded
 > but not Outer, and that getEnclosingClass() caused
 > Outer to be loaded but not initialized.

But we don't see the code he was using,
maybe he can upload his test case on Gist?
Me myself, I am still lagging behind,

still struggling with instrumenting my
application, couldn't yet reproduce
what Eric Sosman wrote on some platform,

not even compiled some test so far...

lewbloch@gmail.com schrieb:
> Marcel Mueller wrote:
>> AFAIK there are no dependencies in static construction of class types,
>> regardless whether they are inner, outer or whatever.
>
> There is no such thing as "static construction" of an inner class, is there?
>
>> The only guarantee is, that a class initialization is run before any
>> member access. No more, no less. So unless you create such a dependency
>> you cannot assume the outer class to be initialized.
>>
>> Of course, the rule "before" is also fulfilled if the outer class would
>> be initialized immediately. So at the end it is implementation defined.
>> But I assume that it is unlikely that an implementation initializes the
>> outer class earlier than required, just because this could break a
>> dependency of Outer on Inner. I.e. if the initialization of the outer
>> class accesses static members of Inner.
>
> Inner classes cannot have static members except for constants.
> http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.1.3
>
> Because an inner class is associated with an instance of its outer class unless declared in a static context, and that instance cannot be created without initializing the outer class, it follows that in order for an inner class to be initialized the outer class must be initialized first.
>
> Likewise a static context won't exist unless its owning class is (being) initialized, so again an inner class cannot be initialized without the enclosing class being initialized, AIUI.
>
> The order of loading and initialization is not "at the end ... implementation defined" but at the beginning specified by the JLS.
> http://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html
>

[toc] | [prev] | [next] | [standalone]

#37463

On 9/24/2017 11:39 AM, j4n bur53 wrote:
> [...]
> 
> itself. Basically Eric Sosman
> already answered:
> 
>  >     java -verbose:class esosman.misc.Foo
>  >
>  > This told me that forName() caused Inner to be loaded
>  > but not Outer, and that getEnclosingClass() caused
>  > Outer to be loaded but not initialized.
> 
> But we don't see the code he was using,
> maybe he can upload his test case on Gist?

     Here it is.  If you change the package name, you will also
need to change the forName() call:

	// Foo.java:
	package esosman.misc;
	public class Foo {
	   public static void main(String[] unused)
	         throws ClassNotFoundException {
	      System.out.println("Calling forName() ...");
	      Class inner = Class.forName("esosman.misc.Outer$Inner");
	      System.out.println("Got class: " + inner);
	      System.out.println("Calling getEnclosingClass() ...");
	      Class outer = inner.getEnclosingClass();
	      System.out.println("Got class: " + outer);
	   }
	}

	// Outer.java:
	package esosman.misc;
	public class Outer {
	   static {
	      System.out.println("Initializing Outer");
	   }

	   static class Inner {
	      static {
	         System.out.println("Initializing Inner");
	      }
	   }
	}

-- 
esosman@comcast-dot-net.invalid
Twelve hundred thirteen days to go.

[toc] | [prev] | [next] | [standalone]

#37468

j4n bur53 wrote:
> My original question is not for inner classes but
> for nested classes. 

Your original question was "Assume I have a nested inner class Inner, ..."

So your original question was about inner classes.

-- 
Lew

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web