• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

When are instance variables placed on the heap?

 
Ranch Hand
Posts: 205
4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
According to K&B an init block runs right after the super() call in the constructor. My question is when are instance variables created. In the following code the compiler doesn't complain about the {y=8;} init code coming before y is declared which seems to mean the y instance variable is created before the init code is run.



The result is 7 9 which means the code acts like



So again, when is the instance variable first made available to use? Thanks!

 
Ranch Hand
Posts: 789
Python C++ Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(From Enthuware)
The order of initialization of a class is:
1. All static constants, variables and blocks.(Among themselves the order is the order in which they appear in the code.)
2. All non static constants, variables and blocks.(Among themselves the order is the order in which they appear in the code.)
3. Constructor.

I take this to mean non-static constants are inited in the order they appear in the code, followed by the non-static variables in the order they appear in the code followed by the non-static blocks in the order they appear in the code, which agrees with what you are seeing. It looks like a discrepancy with K&B on when the constructor runs though.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kendall Ponder wrote:
So again, when is the instance variable first made available to use? Thanks!



Instance variables, that are not compile time constants, may be used right from the very beginning. And prior to being initialized, either by a constructor, instance initializer, etc., it has a default value, which for ints, that value is zero.

Henry
 
Enthuware Software Support
Posts: 4810
52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

So again, when is the instance variable first made available to use? Thanks!


It is not just a question about "when" but also about "what". For example, the following will compile:

but the following will not -


JLS section 8.3.2.3 makes it very clear:


8.3.2.3 Restrictions on the use of Fields during Initialization
The declaration of a member needs to appear textually before it is used only if the member is an instance (respectively static) field of a class or interface C and all of the following conditions hold:
• The usage occurs in an instance (respectively static) variable initializer of C or
in an instance (respectively static) initializer of C.
• The usage is not on the left hand side of an assignment.
• The usage is via a simple name.
• C is the innermost class or interface enclosing the usage.
It is a compile-time error if any of the four requirements above are not met.



HTH,
Paul.
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Kendall Ponder wrote:According to K&B an init block runs right after the super() call in the constructor. My question is when are instance variables created. In the following code the compiler doesn't complain about the {y=8;} init code coming before y is declared which seems to mean the y instance variable is created before the init code is run.


I think you'll understand much better what's happening if you know wht happens behind the scenes if you use an instance initializer block. The code of an initializer block is copied into each constructor of your class, before any statements already present in that constructor. So that explains why an init block runs immediately after the super constructor.

The decompiled code of your Class1 class illustrates this beautifully:So now it should be really obvious why the result is 7 9.

Now what happens if I added another constructor to the Class1 class?Let's find out:The code from the instance initializer block is copied into each constructor which (luckily) confirms my aforementioned statement

If we apply the same technique on Paul's 1st code snippet, you'll get this code:No problem here!

Now Paul's 2nd code snippet doesn't compile, so we can't decompile (because you'll need a .class file), but you try to use the variable y before it's defined and that's not allowed, so you'll get a compiler error.

And now it's up to you to test your knowledge What's the output of this little program?

Hope it helps!
Kind regards,
Roel
 
Guillermo Ishi
Ranch Hand
Posts: 789
Python C++ Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Woot. I answered that. It's not Oracle enough.

The decompiled code shows it's more like the constructor finishes last rather than begins last. And things within the constructor in the source get executed last. So the perception of when the constructor runs depends on point of view - source view or bytecode/reality view. Correct?

 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Guillermo Ishi wrote:The decompiled code shows it's more like the constructor finishes last rather than begins last. And things within the constructor in the source get executed last. So the perception of when the constructor runs depends on point of view - source view or bytecode/reality view. Correct?


I think it doesn't really matter (certanly not for the OCAJP exam) if you know the bytecode or not. You only need to know 2 things for the exam:
  • an instance initializer blocks will run immediately after super constructor
  • if you need the same code in multiple constructors, use an instance initializer block


  • Even the Oracle's Java Tutorial tells you what will happen if you use an instance initializer block:

    Oracle's Java Tutorial wrote:The Java compiler copies initializer blocks into every constructor. Therefore, this approach can be used to share a block of code between multiple constructors.

     
    Guillermo Ishi
    Ranch Hand
    Posts: 789
    Python C++ Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Right. The interesting thing is you can answer the question thinking the constructor runs last, as I was taught, when behinds the scenes it really runs first. But the bytecode demonstration makes it clear what happens when a hierarchy classes including init blocks is initialized. Last thing - I'm surprised the .class file doesn't show the call to super();


     
    Roel De Nijs
    Sheriff
    Posts: 11604
    178
    Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Guillermo Ishi wrote:Last thing - I'm surprised the .class file doesn't show the call to super();


    Indeed! But maybe that's a decompiler thingy. I use the JAD decompiler, maybe you'll get another decompiled class source when you use another decompiler.
     
    Ranch Hand
    Posts: 89
    Python C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Anilprem wrote:
    JLS section 8.3.2.3 makes it very clear:


    8.3.2.3 Restrictions on the use of Fields during Initialization
    The declaration of a member needs to appear textually before it is used only if the member is an instance (respectively static) field of a class or interface C and all of the following conditions hold:
    • The usage occurs in an instance (respectively static) variable initializer of C or
    in an instance (respectively static) initializer of C.
    • The usage is not on the left hand side of an assignment.
    • The usage is via a simple name.
    • C is the innermost class or interface enclosing the usage.
    It is a compile-time error if any of the four requirements above are not met.





    I'm afraid I found it quite confusing. Could you please explain it in simpler terms? :\
     
    Roel De Nijs
    Sheriff
    Posts: 11604
    178
    Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Ashwin Rao wrote:I'm afraid I found it quite confusing. Could you please explain it in simpler terms? :\


    Don't worry! The JLS is sometimes very confusing, even for an experienced java developer like me. That's why I don't recommend reading this document when preparing for the OCAJP exam. It will add more confusion than it will clear your doubts.
     
    Paul Anilprem
    Enthuware Software Support
    Posts: 4810
    52
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Roel De Nijs wrote:

    Ashwin Rao wrote:I'm afraid I found it quite confusing. Could you please explain it in simpler terms? :\


    Don't worry! The JLS is sometimes very confusing, even for an experienced java developer like me. That's why I don't recommend reading this document when preparing for the OCAJP exam. It will add more confusion than it will clear your doubts.


    Respectfully disagree. If you look at this thread itself, no post explains why the second code n my previous post doesn't compile except the quote from JLS. It is true that JLS gets a little terse but confusing it is certainly not. One cannot get more precise and complete explanation than from JLS.

    So my suggestion is if you want to be a good java programmer, get into the habit of checking out the specifications. It may be a little, only a little, hard at first, but you will be a lot happier later

    Ashwin Rao wrote:I'm afraid I found it quite confusing. Could you please explain it in simpler terms? :\


    Can you tell me which sentence of the quote do you have trouble understanding?
     
    Ashwin Rao
    Ranch Hand
    Posts: 89
    Python C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Firstly,In the JLS they've used a term called "respectively static" what does it mean?
    Secondly,In the JLS in the first bullet point, does instance variable inititalizer mean an initializer block and what does instance initializer mean?
    Thirdly,Usage via a simple name means directly using the variable (by only using variable name like y) from inside the class?

    Thanks!
     
    Paul Anilprem
    Enthuware Software Support
    Posts: 4810
    52
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Ashwin Rao wrote:Firstly,In the JLS they've used a term called "respectively static" what does it mean?


    It means the same concept applies to static member as well.


    Secondly,In the JLS in the first bullet point, does instance variable inititalizer mean an initializer block and what does instance initializer mean?


    Yes, same as mentioned in the posts above.


    Thirdly,Usage via a simple name means directly using the variable (by only using variable name like y) from inside the class?

    Thanks!


    Yes.
     
    Roel De Nijs
    Sheriff
    Posts: 11604
    178
    Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Anilprem wrote:

    Ashwin Rao wrote:Firstly,In the JLS they've used a term called "respectively static" what does it mean?


    It means the same concept applies to static member as well.


    Just for clarity: it applies to static members when used/accessed within a static initializer block (with an instance initializer block there's no compiler error).
     
    Ashwin Rao
    Ranch Hand
    Posts: 89
    Python C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks!!
     
    Sheriff
    Posts: 17644
    300
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Anilprem wrote:...no post explains why the second code n my previous post doesn't compile except the quote from JLS. It is true that JLS gets a little terse but confusing it is certainly not. One cannot get more precise and complete explanation than from JLS.


    I'm yer huckleberry...

    Can you tell me which sentence of the quote do you have trouble understanding?


    The whole section you quoted has some pretty twisty logic and, judging from the difficulty folks are having understanding it, I would also respectfully disagree with your assertion that it's very clear and that it's not confusing. Honestly, I do find it confusing.

    Let's take a look at it again:

    8.3.2.3 Restrictions on the use of Fields during Initialization

    The declaration of a member needs to appear textually before it is used only if the member is an instance (respectively static) field of a class or interface C and all of the following conditions hold:
  • The usage occurs in an instance (respectively static) variable initializer of C or in an instance (respectively static) initializer of C.
  • The usage is not on the left hand side of an assignment.
  • The usage is via a simple name.
  • C is the innermost class or interface enclosing the usage.

  • It is a compile-time error if any of the four requirements above are not met.

    Now let's look at your code that produces a compile-time error (Cannot reference a field before it is declared):

    According to the JLS, you will get a compile-time error if any of the four requirements are not met. In other words, all four conditions must be true in order for the code to compile without error:
    1. Check - usage of y on line 3 is inside an instance initializer
    2. Check - usage of y on line 3 is not on the left hand side of an assignment
    3. Check - usage is via a simple name; y is a simple name (vs a qualified name, a name consisting of a series of identifiers separated by "." tokens)
    4. Check - TestClass is the innermost class enclosing the usage.

    But wait, if all these conditions hold, why do we still get and, in fact, expect a compile-time error?

    Now here's the twisty logic: If you look at the lead-in statement, it says "The declaration of a member needs to appear textually before it is used only if the member is an instance (respectively static) field..." Therefore, if all the conditions hold, then the lead-in condition that "the declaration of a member needs to appear textually before it is used" is enforced by the compiler. There's the answer: we get a compiler error because the condition in the lead-in statement has been violated, not because one of the four dependent conditions given did not hold.

    If I were to hazard a guess, I would think whoever wrote this was a lawyer or something -- no offense to any who might be reading this. I think a normal person who isn't already very familiar with the JLS and how this particular thing works really has to sit there and work through that logic to see how it applies to the code sample you gave, Paul. I know I did. (But then again, I've been told that I'm not normal before, too )
     
    Ashwin Rao
    Ranch Hand
    Posts: 89
    Python C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I'm currently working on encryption and decryption for my project. I should find the guy who wrote the JLS to help me better understand encryption!!
     
    Junilu Lacar
    Sheriff
    Posts: 17644
    300
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Good one, Ashwin.
     
    Paul Anilprem
    Enthuware Software Support
    Posts: 4810
    52
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:

    Paul Anilprem wrote:...no post explains why the second code n my previous post doesn't compile except the quote from JLS. It is true that JLS gets a little terse but confusing it is certainly not. One cannot get more precise and complete explanation than from JLS.


    I'm yer huckleberry...

    Can you tell me which sentence of the quote do you have trouble understanding?


    The whole section you quoted has some pretty twisty logic and, judging from the difficulty folks are having understanding it, I would also respectfully disagree with your assertion that it's very clear and that it's not confusing. Honestly, I do find it confusing.

    Let's take a look at it again:

    8.3.2.3 Restrictions on the use of Fields during Initialization

    The declaration of a member needs to appear textually before it is used only if the member is an instance (respectively static) field of a class or interface C and all of the following conditions hold:
  • The usage occurs in an instance (respectively static) variable initializer of C or in an instance (respectively static) initializer of C.
  • The usage is not on the left hand side of an assignment.
  • The usage is via a simple name.
  • C is the innermost class or interface enclosing the usage.

  • It is a compile-time error if any of the four requirements above are not met.

    Now let's look at your code that produces a compile-time error (Cannot reference a field before it is declared):

    According to the JLS, you will get a compile-time error if any of the four requirements are not met. In other words, all four conditions must be true in order for the code to compile without error:
    1. Check - usage of y on line 3 is inside an instance initializer
    2. Check - usage of y on line 3 is not on the left hand side of an assignment
    3. Check - usage is via a simple name; y is a simple name (vs a qualified name, a name consisting of a series of identifiers separated by "." tokens)
    4. Check - TestClass is the innermost class enclosing the usage.

    But wait, if all these conditions hold, why do we still get and, in fact, expect a compile-time error?

    Now here's the twisty logic: If you look at the lead-in statement, it says "The declaration of a member needs to appear textually before it is used only if the member is an instance (respectively static) field..." Therefore, if all the conditions hold, then the lead-in condition that "the declaration of a member needs to appear textually before it is used" is enforced by the compiler. There's the answer: we get a compiler error because the condition in the lead-in statement has been violated, not because one of the four dependent conditions given did not hold.

    If I were to hazard a guess, I would think whoever wrote this was a lawyer or something -- no offense to any who might be reading this. I think a normal person who isn't already very familiar with the JLS and how this particular thing works really has to sit there and work through that logic to see how it applies to the code sample you gave, Paul. I know I did. (But then again, I've been told that I'm not normal before, too )



    You are right. The way you have interpreted it, it does look confusing. To be honest, I interpreted the second condition "The usage is not on the left hand side of an assignment." more liberally and considered that passing a variable to a method belongs to the same category (because you are assigning the variable's value to the method parameter). My understanding is that the code doesn't compile because it violates this condition.


     
    Junilu Lacar
    Sheriff
    Posts: 17644
    300
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Anilprem wrote:

  • The usage is not on the left hand side of an assignment.


  • 2. Check - usage of y on line 3 is not on the left hand side of an assignment

    ... I interpreted the second condition "The usage is not on the left hand side of an assignment." more liberally and considered that passing a variable to a method belongs to the same category (because you are assigning the variable's value to the method parameter). My understanding is that the code doesn't compile because it violates this condition.


    Ah, but herein lies the rub: the JLS says "the usage is not on the left hand side" - the usage of y here, if you interpret it loosely as an assignment of a value to the method parameter, would be methodParameter = y, so the condition would still be satisfied because y is on the right hand side, not on the left hand side of that assignment. See, even in your interpretation the JLS got you confused.
     
    Paul Anilprem
    Enthuware Software Support
    Posts: 4810
    52
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:

    Paul Anilprem wrote:

  • The usage is not on the left hand side of an assignment.


  • 2. Check - usage of y on line 3 is not on the left hand side of an assignment

    ... I interpreted the second condition "The usage is not on the left hand side of an assignment." more liberally and considered that passing a variable to a method belongs to the same category (because you are assigning the variable's value to the method parameter). My understanding is that the code doesn't compile because it violates this condition.


    Ah, but herein lies the rub: the JLS says "the usage is not on the left hand side" - the usage of y here, if you interpret it loosely as an assignment of a value to the method parameter, would be methodParameter = y, so the condition would still be satisfied because y is on the right hand side, not on the left hand side of that assignment. See, even in your interpretation the JLS got you confused.


    No, with my interpretation it makes perfect sense. If you remove all the irrelevant (for this particular situation) parts, it says, "The declaration of a member needs to appear textually before it is used .... if the usage is not on the left hand side of an assignment. " This is exactly the case if you consider passing a variable to a method call same as not being on left hand side of an assignment.
     
    Junilu Lacar
    Sheriff
    Posts: 17644
    300
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    But I don't see the "only if" part of the lead-in statement as being irrelevant. Anyway, this just proves the point that the JLS can be a source of confusion and what it really says is up for interpretation, of which we've seen there can be a few conflicting ones. At any rate, I think my logic and analysis are sound and that the problem is with the condition specified in the lead-in statement, not that y was passed as a parameter to a method. If the JLS authors are so precise and unambiguous, why would they not explicitly cite that as a condition and leave it up for "loose interpretations"?
     
    Paul Anilprem
    Enthuware Software Support
    Posts: 4810
    52
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:But I don't see the "only if" part of the lead-in statement as being irrelevant. Anyway, this just proves the point that the JLS can be a source of confusion and what it really says is up for interpretation, of which we've seen there can be a few conflicting ones. At any rate, I think my logic and analysis are sound and that the problem is with the condition specified in the lead-in statement, not that y was passed as a parameter to a method. If the JLS authors are so precise and unambiguous, why would they not explicitly cite that as a condition and leave it up for "loose interpretations"?


    Nobody is perfect. I only claimed that JLS is more precise and complete than any other resource. You still haven't shown any evidence to the contrary
     
    Guillermo Ishi
    Ranch Hand
    Posts: 789
    Python C++ Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    The simple name bullet might be messed up too, since this compiles fine.

     
    Junilu Lacar
    Sheriff
    Posts: 17644
    300
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Anilprem wrote:Nobody is perfect... You still haven't shown any evidence to the contrary


    I believe I (and inadvertently/unwittingly, you) have. Are you one of those climate change deniers, too? (just kidding)
     
    Junilu Lacar
    Sheriff
    Posts: 17644
    300
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Guillermo Ishi wrote:The simple name bullet might be messed up too, since this compiles fine.


    Good catch, Guillermo. The output when you instantiate TestClass is 0, the default value assigned to an int instance member. This would refute Paul's assertion that passing y as a parameter to a method is in violation of the second condition specified by the JLS. Those guys are not infallible, you know.
     
    Kendall Ponder
    Ranch Hand
    Posts: 205
    4
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    The declaration of a member needs to appear textually before it is used only if the member is an instance (respectively static) field of a class or interface C and all of the following conditions hold:



    I'm either not following the conversation between Paul and Junilu or else I'm not following the JLS. What does appearing textually before it is used mean? I thought it meant the member only had to be declared first if all of the conditions were met. It appears Paul and Junilu are interpreting it to mean the exact opposite. When I applied my interpretation to Paul's two snippets.
    Snippet A

    Snippet B


    The usage occurs in an instance (respectively static) variable initializer of C or in an instance (respectively static) initializer of C.
    The usage is not on the left hand side of an assignment.
    The usage is via a simple name.
    C is the innermost class or interface enclosing the usage.


    In snippet A the usage of y is on the left side of an assignment so all four conditions are not met (to be met the useage must not be on the left side) so the y=8; can appear before the int y=10; in the code. In snippet B all four conditions are met so the System.out.println(y); must appear after the int y=10; and since it does not you get a compiler error. Do I have this backwards?
     
    Kendall Ponder
    Ranch Hand
    Posts: 205
    4
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Secondly,In the JLS in the first bullet point, does instance variable inititalizer mean an initializer block and what does instance initializer mean?



    Yes, same as mentioned in the posts above.


    Paul, I don't think you answered the second part of the question (I had the same question). What is the difference between an instance variable initializer and an instance initializer? Thanks!
     
    Kendall Ponder
    Ranch Hand
    Posts: 205
    4
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Guillermo Ishi wrote:The simple name bullet might be messed up too, since this compiles fine.



    This fits my interpretation. this.y is not a simple name so one of the four conditions is not met so int y=20; does not need to appear contextually before this.y so the code compiles fine.
     
    Kendall Ponder
    Ranch Hand
    Posts: 205
    4
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Roel De Nijs wrote:

    Kendall Ponder wrote:According to K&B an init block runs right after the super() call in the constructor. My question is when are instance variables created. In the following code the compiler doesn't complain about the {y=8;} init code coming before y is declared which seems to mean the y instance variable is created before the init code is run.



    And now it's up to you to test your knowledge What's the output of this little program?

    Hope it helps!
    Kind regards,
    Roel


    I think it would be
    0a0c15d15b
     
    Kendall Ponder
    Ranch Hand
    Posts: 205
    4
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Henry Wong wrote:

    Kendall Ponder wrote:
    So again, when is the instance variable first made available to use? Thanks!



    Instance variables, that are not compile time constants, may be used right from the very beginning. And prior to being initialized, either by a constructor, instance initializer, etc., it has a default value, which for ints, that value is zero.

    Henry



    Could you give me an example of a compile time constant which would not be available from the beginning? Thanks!
     
    Paul Anilprem
    Enthuware Software Support
    Posts: 4810
    52
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:

    Paul Anilprem wrote:Nobody is perfect... You still haven't shown any evidence to the contrary


    I believe I (and inadvertently/unwittingly, you) have.


    Well, I am not the author of JLS so I am not emotionally attached to it. If you tell me which resource is better than JLS, I will check it out. So far I havent seen any reference from you.

    Oh , and climate is changing . for sure
     
    Paul Anilprem
    Enthuware Software Support
    Posts: 4810
    52
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Kendall Ponder wrote:

    Secondly,In the JLS in the first bullet point, does instance variable inititalizer mean an initializer block and what does instance initializer mean?



    Yes, same as mentioned in the posts above.


    Paul, I don't think you answered the second part of the question (I had the same question). What is the difference between an instance variable initializer and an instance initializer? Thanks!


    Sorry, I'm away from my m/c right now. Need to confirm before responding. Will do it later today.
     
    Junilu Lacar
    Sheriff
    Posts: 17644
    300
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Kendall Ponder wrote:I thought it meant the member only had to be declared first if all of the conditions were met.
    ...
    Do I have this backwards?


    That is my interpretation, too. No, I don't think you have it backwards, otherwise, I'd have it backwards too and I don't think I have it backwards. Unless of course we're now smack dab in the Twilight Zone.... (na na nah, na na nah...)

    Since all the conditions appear to have been met, then the member declaration needs to appear textually before it is used. That means the declaration has to be on a line above any line where it is used. However, the JLS is confusing because it closes that section with this statement "It is a compiler error if any of the four requirements above are not met." In the code under discussion, y is not declared first and there was a compiler error. My assertion is that the compile-time error was because the code did not conform to the part that says "the member declaration needs to appear before it is used," and not because the condition that "The usage is not on the left hand side of an assignment" was not satisfied. Again, my contention is that the condition WAS indeed satisfied. That is, System.out.println(y) satisfies the condition "The usage is not on the left hand side of an assignment." This statement is true: The usage of y is NOT on the left hand side of an assignment. This is not an assignment statement; it's a method call with y being passed as a parameter.

    Now, even if you take Paul's loose interpretation and see it as assigning the value of y to a method parameter, that is, methodParameter = y, the condition is still satisfied because here, y is on the RIGHT-hand side of the assignment and NOT on the LEFT-hand side.

    LEFT-hand side = RIGHT-hand side
    methodParameter = y

    Does the JLS now have us confusing which side is left and which side is right? Or is it confusing because of all these "not"s?
     
    Paul Anilprem
    Enthuware Software Support
    Posts: 4810
    52
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Kendall Ponder wrote:

    The declaration of a member needs to appear textually before it is used only if the member is an instance (respectively static) field of a class or interface C and all of the following conditions hold:



    I'm either not following the conversation between Paul and Junilu or else I'm not following the JLS. What does appearing textually before it is used mean? I thought it meant the member only had to be declared first if all of the conditions were met. It appears Paul and Junilu are interpreting it to mean the exact opposite. When I applied my interpretation to Paul's two snippets.
    Snippet A

    Snippet B


    The usage occurs in an instance (respectively static) variable initializer of C or in an instance (respectively static) initializer of C.
    The usage is not on the left hand side of an assignment.
    The usage is via a simple name.
    C is the innermost class or interface enclosing the usage.


    In snippet A the usage of y is on the left side of an assignment so all four conditions are not met (to be met the useage must not be on the left side) so the y=8; can appear before the int y=10; in the code. In snippet B all four conditions are met so the System.out.println(y); must appear after the int y=10; and since it does not you get a compiler error. Do I have this backwards?



    You got it. Im interpreting it the same way. Im not sure what is Junilu's interpretation.
     
    Roel De Nijs
    Sheriff
    Posts: 11604
    178
    Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Kendall Ponder wrote:

    Secondly,In the JLS in the first bullet point, does instance variable inititalizer mean an initializer block and what does instance initializer mean?



    Yes, same as mentioned in the posts above.


    Paul, I don't think you answered the second part of the question (I had the same question). What is the difference between an instance variable initializer and an instance initializer? Thanks!


    The instance initializer has its own section in the JLS So that's what we know as an instance initializer block (or an init block). Like this:
    The instance variable initializer is like its name suggest: an initializer for an instance variableThe right-hand side of the equals sign in an initializer can be any expression that evaluates to the type of the instance variable.
     
    Junilu Lacar
    Sheriff
    Posts: 17644
    300
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Paul Anilprem wrote:
    You got it. Im interpreting it the same way. Im not sure what is Junilu's interpretation.


    If I'm interpreting the same way that Kendall is interpreting and you're interpreting the same way Kendall is interpreting, then we should both be in agreement. I guess I just didn't express myself clearly enough.
     
    Junilu Lacar
    Sheriff
    Posts: 17644
    300
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    One last run at this to try to make it clear:

    Kendall Ponder wrote:
    Snippet B

    ...
    The usage is not on the left hand side of an assignment.
    ...
    In snippet B all four conditions are met so the System.out.println(y); must appear after the int y=10; and since it does not you get a compiler error. Do I have this backwards?


    What Kendall is saying:

    In snippet B, all four conditions (including the condition "The usage is not on the left hand side of an assignment") are met (they are all true) by System.out.println(y);
    Since System.out.println(y) does not appear after the declaration int y = 10;, you get a compiler error.

    Paul, you are contradicting yourself when you say in a previous reply:

    I interpreted the second condition "The usage is not on the left hand side of an assignment." more liberally and considered that passing a variable to a method belongs to the same category (because you are assigning the variable's value to the method parameter). My understanding is that the code doesn't compile because it violates this condition"



    So, how can you say that you and Kendall are saying the same thing when he says that the condition is met and you contend that the condition has been violated?


     
    Kendall Ponder
    Ranch Hand
    Posts: 205
    4
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Roel De Nijs wrote:

    Kendall Ponder wrote:

    Secondly,In the JLS in the first bullet point, does instance variable inititalizer mean an initializer block and what does instance initializer mean?



    Yes, same as mentioned in the posts above.


    Paul, I don't think you answered the second part of the question (I had the same question). What is the difference between an instance variable initializer and an instance initializer? Thanks!


    The instance initializer has its own section in the JLS So that's what we know as an instance initializer block (or an init block). Like this:
    The instance variable initializer is like its name suggest: an initializer for an instance variableThe right-hand side of the equals sign in an initializer can be any expression that evaluates to the type of the instance variable.



    Got it (saying it was an init block turned the light on). Thanks!
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic