1

for the following code:

class Parent {
    public void say(){
        System.out.println("Parent");
    }
}

class Child extends Parent{
    public void say(){
        System.out.println("Parent");
    }
}

class Test {
    public static void main(String[] args){

        Parent p = new Child(); // What does the compiler check  
        p.say();
    }
}

The following questions have always confused me.

1. what exacly is happening during compile time? How does the comiler know that Parent p = new Child() is a valid code as no object has been created at compile time?

2. what exactly is hapenning at runtime? How is memory allocated

3. The implicit call to parent's constructor creates an Parent Object. A child object is also created. How is it stored and how does jvm use this for method resolution.

4. Lastly, is JVM hardcoded not to ovverride static methods and variables or there is some other reason. Why can't we use Runtime objects instance method() why not runtime objects variables

Where can I read more on these topics?

Thanks

lynxx
  • 544
  • 3
  • 18
  • 2
    Please ask **one** real question per question, not 4. And you better immediately remove that last sentence about giving links to you, as such requests are off topic here. – GhostCat Jul 01 '19 at 05:00
  • 1
    I tried to answer your questions, but the last one is just too unclear btw. – GhostCat Jul 01 '19 at 05:07
  • 2
    3 - calling a constructor does **not** create an instance, it only initializes (part of) it. `new` creates the new instance (and there is no `new` statement for the parent) – user85421 Jul 01 '19 at 05:19
  • Google all of those questions individually, and you will find your answers. They are all great questions to seek answers too as well, keep searching – Joe Jul 01 '19 at 05:24
  • @Joe trust me there are no good enough articles out there. – lynxx Jul 01 '19 at 10:49
  • @lynxx Honestly, I doubt that. And as said: whole books are written about some of your "sub questions". Complex topics can't always be reduced to a nice short article that tells you all the details. – GhostCat Jul 02 '19 at 07:49
  • @GhostCat just a last quick question. Is it worthy to read java language specifications and jvm specification? Especially at this stage where i just finished basic java course. – lynxx Jul 02 '19 at 13:54
  • 1
    I appreciate the quick comeback. Regarding your question: that really depends. When you really want to be an expert in Java, and when you study computer science, or when for some reason *compiler construction* is a subject that matters to you ... then studying documents such as the JLS or the Java bytecode specification is definitely worthwhile. But more on an "informal" level. There is no point in *memorizing* all details (like grammar rules, or byte code opcodes). But especially the JLS does a great deal *explaining* java. – GhostCat Jul 02 '19 at 13:58

1 Answers1

3

exactly is happening during compile time? How does the comiler know that Parent p = new Child() is a valid code as no object has been created at compile time?

Well, whole books are written about that subject. In essence, the compiler parses the input source, and it finds that assignment:

Parent p = new Child(); 

And now the compiler does two things:

  • it checks what it can find out about the types on both sides of the assignment
  • thus it finds: the left hand side needs an object of type `Parent``
  • it also looks at the right hand side, to understand the (potential) result types that comes out of that expression

So, in the end, the compiler will see: "I need a Parent ... and I get something that is a Child." Then the compiler has to check if an instance of Child satisfies "I need a Parent". And obviously: it does.

what exactly is happening at runtime? How is memory allocated

Again, whole books are written about that. See here for example.

The implicit call to parent's constructor creates an Parent Object. A child object is also created. How is it stored and how does jvm use this for method resolution.

The JVM "simply" knows two things:

  • when reserving the memory for a Child object, it needs to also consider the memory required for any super class fields
  • so, in the end, you simply have one area of memories large enough to hold all fields of all parent classes, down to the Child class itself

Finally: static methods are inherented, but yes, there is no polymorphism for them in Java. That is simply a design point of the language, and the semantics that are defined for Java. It could be done differently, but 20+ ago, the fathers of Java decided to do it like they did.

GhostCat
  • 137,827
  • 25
  • 176
  • 248