Do upper bounded wildcards restrict you to having only one type of object in a list?

[Anil Philip]

I thought I understood the concept... but I guess, not.

I thought that

List<? extends BigCat>

is immutable ensures that only one type of cat will be in the list. To prevent dissimilar subtypes in the list.
Then why does this compile and run?

Output:

[Lion{}, Tiger{}, BigCat{}]

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

public class Generics {

    static class Animal {
        @Override
        public String toString() {
            return "Animal{}";
        }
    }
    static class BigCat extends Animal {
        @Override
        public String toString() {
            return "BigCat{}";
        }
    }
    static class Lion extends BigCat {
        @Override
        public String toString() {
            return "Lion{}";
        }
    }
    static class Tiger extends BigCat {
        @Override
        public String toString() {
            return "Tiger{}";
        }
    }
    static void f0() {
        List<? extends BigCat> cats = Arrays.asList(new Lion(), new Tiger(), new BigCat());
        System.out.println(cats);
    }

    public static void main(String[] args) {
        f0();
    }
}

[Paul Clapham]

Anil Philip wrote:I thought I understood the concept... but I guess, not.

I thought that

List<? extends BigCat>

is immutable ensures that only one type of cat will be in the list. To prevent dissimilar subtypes in the list.

It doesn't mean that at all. What it means is that the List which is assigned to the variable of type List<? extends BigCat> is in fact of type List<X> for some specific type X which extends BigCat.

In this case X is BigCat itself. So all elements in the List are of type BigCat, as you can see, and you have a List<BigCat>. It's true that some of them are elements of a strict subtype of BigCat, but that doesn't matter.

Imagine that your Lion class had some subclasses (e.g. AfricanLion and DetroitLion). If you put only various objects of those types into your List<? extends BigCat> instead then you have a List<Lion>, even if the elements of that list are in various subclasses of Lion. So do you have "only one type of cat" because you only have Lions, or do you have "more than one type of cat" because you have more than one subclass of Lion? Are those "dissimilar" subtypes or not?

In other words, "dissimilar subtypes" isn't part of the rule.

[Anil Philip]

Thank you for your reply.
I get it that the list contains BigCats.
But why is the list immutable?

Paul Clapham wrote:

Anil Philip wrote:I thought I understood the concept... but I guess, not.

I thought that

List<? extends BigCat>

is immutable ensures that only one type of cat will be in the list. To prevent dissimilar subtypes in the list.

It doesn't mean that at all. What it means is that the List which is assigned to the variable of type List<? extends BigCat> is in fact of type List<X> for some specific type X which extends BigCat.

In this case X is BigCat itself. So all elements in the List are of type BigCat, as you can see, and you have a List<BigCat>. It's true that some of them are elements of a strict subtype of BigCat, but that doesn't matter.

[Paul Clapham]

What the compiler knows is that the list will be a List<X> for some X which is a subtype of BigCat. And it doesn't know what X will be. So it can't let you add a Lion object to the list because X might turn out to be Tiger at run time. Likewise for any subclass of BigCat.

[Ron McLeod]

Anil Philip wrote:But why is the list immutable?

I didn't see anything in your example code which showed immutability.  I'm guessing that you tried to do something to the list created using Arrays#asList?

Arrays#asList creates a list which is backed by the provided array.  The array size is fixed so you can not add or remove any elements.

jshell> var arr = new String[] {"apple", "banana"};
arr ==> String[2] { "apple", "banana" }

jshell> var list = Arrays.asList(arr);
list ==> [apple, banana]

jshell> list.add("cherry");
|  Exception java.lang.UnsupportedOperationException
|        at AbstractList.add (AbstractList.java:153)
|        at AbstractList.add (AbstractList.java:111)
|        at (#6:1)

You can however change the value of the elements in the list (actually the array).

jshell> list.set(1, "blueberry");
$7 ==> "banana"

jshell> list;
list ==> [apple, blueberry]

jshell> arr;
arr ==> String[2] { "apple", "blueberry" }

Javadoc wrote:Returns a fixed-size list backed by the specified array. Changes made to the array will be visible in the returned list, and changes made to the list will be visible in the array. The returned list is Serializable and implements RandomAccess.
The returned list implements the optional Collection methods, except those that would change the size of the returned list. Those methods leave the list unchanged and throw UnsupportedOperationException.

[Paul Clapham]

Ron McLeod[url=https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Arrays.html#asList(T...) wrote:Arrays#asList[/url] creates a list which is backed by the provided array.  The array size is fixed so you can not add or remove any elements.

This is also true. My reply was about a different sort of "immutability" which isn't usually referred to as such.

[Paul Anilprem]

>I thought that List<? extends BigCat> is immutable

That thinking is incorrect. When you define a variable as List<? extends BigCat>, that doesn't mean whatever object that variable points to is immutable! <br /> Defining a variable a certain way only defines the compiler's view of that variable. It has no bearing on the actual object. In this case, it only means that the variable points to a List of BigCats. Which exact subclass of BigCat, it doesn't know. Since the compiler has no information about the actual List, it doesn't let you add anything to it using that variable.

The actual list object might have come from elsewhere and might contain anything, But that is immaterial because the compiler's view is filtered by the variable definition.

[Anil Philip]

Paul Clapham wrote:So it can't let you add a Lion object to the list because X might turn out to be Tiger at run time. Likewise for any subclass of BigCat.

.

But as long as it's a BigCat, what's wrong with that? Please see my example. The list has a Lion, Tiger and BigCat.

[Anil Philip]

Ron McLeod wrote:

Anil Philip wrote:But why is the list immutable?

I didn't see anything in your example code which showed immutability.  

As far as I know, all lists that use an extends wildcard are immutable - even those backed by ArrayList.
I thought that was a fact

This does not compile

        ArrayList<? extends BigCat> arrayList = new ArrayList<>();
        arrayList.add(new Lion()); // DOES NOT COMPILE

java: incompatible types: Generics.Lion cannot be converted to capture#1 of ? extends Generics.BigCat

[Ron McLeod]

In https://coderanch.com/t/584247/java/wildcard-extends-ensures-Immutability:

Rob Spoor wrote:... As for the immutability - although you cannot add any objects to a List<? extends T>, you can indeed add null, and you can also remove elements. In other words, the extends wildcard never ensures immutability.

[Anil Philip]

Paul Anilprem wrote:>Which exact subclass of BigCat, it doesn't know. Since the compiler has no information about the actual List, it doesn't let you add anything to it using that variable.

From your statement (if I understood you correctly), you are assuming that every element in the list is the same subtype.
But from Paul's reply above and also from my example, the elements are dissimilar (but all are BigCats).

Output:

[Lion{}, Tiger{}, BigCat{}]

So if the compiler allows dissimilar types as above, why doesn't it allow adding to the list - as long as each element is a BigCat?

It should allow

arrayList.add(new Lion());
arrayList.add(new Tiger());
arrayList.add(new BigCat());

[Paul Anilprem]

Anil Philip wrote:

Paul Anilprem wrote:>Which exact subclass of BigCat, it doesn't know. Since the compiler has no information about the actual List, it doesn't let you add anything to it using that variable.

From your statement (if I understood you correctly), you are assuming that every element in the list is the same subtype.

No, I am not making any assumption about what the list actually contains. Which statement of mine gave you that impression? In fact, I clearly wrote that the actual list object might have come from elsewhere and might contain anything.
The issue is not with the object at all. The issue is with the variable type.

[Anil Philip]

Paul Anilprem wrote:
No, I am not making any assumption about what the list actually contains. Which statement of mine gave you that impression? In fact, I clearly wrote that the actual list object might have come from elsewhere and might contain anything.

Ok.

        List<BigCat> bigCats = new ArrayList<>();
        bigCats.add(new Lion());
        bigCats.add(new Tiger());
        bigCats.add(new BigCat());
        System.out.println(bigCats);

Output:

[Lion{}, Tiger{}, BigCat{}]

Why is this allowed?

[Paul Anilprem]

You mean, why does the compiler allow bigCats.add(any BigCat) ? Because you have defined bigCats as a List of BigCats and you are adding BigCats. There is no contradiction. Why should the compiler not allow that?

This is very different from List<? extends BigCats<). This is not a list of BigCats. It is a list of some specific (but unknown to compiler) subclass of BigCats. <br />
(Removed quote as per CR policy).

[Paul Clapham]

It should be clear by now, but just to reiterate: In your example a Lion IS-A BigCat, and so is a Tiger and even a BigCat. That's a fundamental rule of Java inheritance.

[Anil Philip]

Paul Anilprem wrote:
Which exact subclass of BigCat, it doesn't know. Since the compiler has no information about the actual List,
.....
This is very different from List<? extends BigCats<). This is not a list of BigCats. It is a list of some specific (but unknown to compiler) subclass of BigCats.

<br />
The statements above are where I have the problem in understanding.
The compiler knows what you are adding to the list and whether it is a legal subtype.
Hence it should allow adds()

When the compiler sees

        List<? extends BigCat> list = new ArrayList<Lion>();

It should know this is a list of subtype Lion.

Or when it sees

        List<? extends BigCat> list = new ArrayList<>();

and somewhere else,

        list.add(new Lion());

It should know we are adding a Lion, which is a subtype of BigCat.

When it sees

        List<? extends BigCat> cats = Arrays.asList(new Lion(), new Tiger(), new BigCat());

It should know we have a mixture of subtypes.

[Paul Clapham]

Anil Philip wrote:Or when it sees

        List<? extends BigCat> list = new ArrayList<>();

and somewhere else,

        list.add(new Lion());

It should know we are adding a Lion, which is a subtype of BigCat.

You surely don't mean to suggest that the compiler will resolve the type of the "list" variable by scanning the entire program to see where elements might be added to the list? It needs to assign the type by looking at that line of code only. And no, we've already been through this, List<? extends BigCat> is not the same as List<BigCat>.

[Paul Clapham]

In most cases you're going to have List<? extends BigCat> test = ... assigned the result of a method call or the value of a method parameter. This says that it's going to be assigned a value which is a List<X> where X is a subtype of BigCat. But you can't know what X is at runtime because (by design) the JVM can't look at a List<> object and find out what its type parameter is. (This is important.) <br /> So the compiler won't make any assumptions about X either. All the compiler knows is that its type parameter is going to be a subclass of BigCat, but it can't know which subclass. <br /> <br /> You inadvertently muddied the water by devising an example where it appears to be possible to find out the type of a List which is being created in front of your eyes. But it actually isn't possible. List.of(new Lion()) is not a List<Lion>.

So all the compiler knows about List<? extends BigCat> is that it's a list of some unknown type X. It is not a List<BigCat>. This means that you can't add an object to that list because the compiler doesn't know whether the type of that object will be a subtype of X at run time. <br /> <br /> Did you compile those code samples you originally posted? I have a feeling many of them won't compile correctly.

[Anil Philip]

Paul Clapham wrote:
You surely don't mean to suggest that the compiler will resolve the type of the "list" variable by scanning the entire program to see where elements might be added to the list? It needs to assign the type by looking at that line of code only. And no, we've already been through this, List<? extends BigCat> is not the same as List<BigCat>.

I think there is a miscommunication.
The compiler will look at the "add()" and verify it is a type of BigCat.
When it looks at the declaration of the list, it will determine what kind of list. Please see my post again.

             List<? extends BigCat> list = new ArrayList<Lion>();

[Anil Philip]

Paul Clapham wrote:Did you compile those code samples you originally posted? I have a feeling many of them won't compile correctly.

Which ones?

[Paul Clapham]

Anil Philip wrote:
The compiler will look at the "add()" and verify it is a type of BigCat.
When it looks at the declaration of the list, it will determine what kind of list. Please see my post again.

             List<? extends BigCat> list = new ArrayList<Lion>();

You could have considered trying that to see if it works; you will find that

list.add(new Lion());

as the next line of code does not compile. That's because List<? extends BigCat> is not a List<Lion> and it cannot be one. Like I said, the compiler usually can't assign a particular type to ? in this construction. The fact that you've provided a special case where it might be able to assign Lion to ? doesn't mean that it does that. The compiler works to a specific rule and having it make exceptions for code which don't have to be written that way is not what compiler writers do.

Several of us have already explained how this works. You should now take some examples and examine them closely. Trying to explain to us how it works differently should no longer be practical.

[Paul Clapham]

I notice that throughout this thread we have been a bit sloppy about the difference between references and the objects they refer to. Consider this:

Object lion = new Lion();

This is unremarkable code, but note: We have a Lion object and a variable of Object type which refers to it. And so the "lion" variable cannot be used to refer to Lion methods. I don't think your original code actually had any Lion methods which weren't inherited from Object, but let's suppose there was a "vocalise()" method. The "lion" variable can't call that method.

But you know that already. What we were doing earlier was talking about

List<? extends BigCat> list = new ArrayList<Lion>();

and saying things like "list is an ArrayList<Lion> object" (although not exactly those words). But the object referred to is a List<Lion> object; the variable referring to it is a List<? extends BigCat> variable. And the compiler can't assign a known type to ?, because that's how the compiler works. So "list" is of type List<?> where ? is an unknown subclass of BigCat. It is not of type List<Lion> because the compiler is unable to determine that, regardless of whether it sure looks like it ought to be able to.

One more thing: you might think we ought to be able to cast that variable back to a List<Lion>. Like this:

List<Lion> test = (List<Lion>) list;

But you can't even do that. Because of type erasure it isn't possible for the JVM to examine a List object and figure out that it was created as a List<T> object.

[Paul Anilprem]

Right, that is exactly where OP's confusion stems from, which I addressed in my first post, I think:

Since the compiler has no information about the actual List, it doesn't let you add anything to it using that variable.
The actual list object might have come from elsewhere and might contain anything, But that is immaterial because the compiler's view is filtered by the variable definition.

As any Java certification student will know, the compiler is always worried about the variable type. It has no idea about the actual object pointed to by the variable and so all decisions taken by the compiler are based on the variable type and not the actual object type. This theme is beaten to death for all rules (overloading, overriding, covariant returns etc.) that an OCA/OCP aspirant has to learn  

Generics is compile time magic only.

[Henry Wong]

Anil Philip wrote:
I think there is a miscommunication.
The compiler will look at the "add()" and verify it is a type of BigCat.
When it looks at the declaration of the list, it will determine what kind of list. Please see my post again.

             List<? extends BigCat> list = new ArrayList<Lion>();

Unfortunately, the compiler is not able to determine the type of the list object. It must follow the Java Specification and there isn't any part of it that allows it to figure it out based on the assignment. Also, just because you can figure it out in your example, it doesn't mean that the specification can be done to allow the compiler to figure it out in all cases. For example, what if you changed the assignment to a method parameter? In that case, you won't be able to figure out the original type -- so, how do you expect the compiler to figure it out?

Henry

[Anil Philip]

Paul Clapham wrote:
You could have considered trying that to see if it works; you will find that

list.add(new Lion());

as the next line of code does not compile.

I repeat, there is a miscommunication.
I never said that it compiles.
I know that it does not because the list is immutable (you cannot add to it).
I even copy-pasted the compiler error message here:
coderanch.com/t/776983/certification/upper-bounded-wildcards-restrict-type#3551862

[Anil Philip]

Henry Wong wrote: Also, just because you can figure it out in your example, it doesn't mean that the specification can be done to allow the compiler to figure it out in all cases. For example, what if you changed the assignment to a method parameter? In that case, you won't be able to figure out the original type -- so, how do you expect the compiler to figure it out?
Henry

Thank you for your reply.

Here is my modified example code to test what you wrote.
I am passing the list using method parameters.
Class PussyCat is not a BigCat and the compiler is able to figure it out and give this error.

java: incompatible types: java.util.List<Generics.PussyCat> cannot be converted to java.util.List<? extends Generics.BigCat>

import java.util.*;

public class Generics {

    static class Animal {
        @Override
        public String toString() {
            return "Animal{}";
        }
    }
    static class PussyCat extends Animal {
        @Override
        public String toString() {
            return "PussyCat{}";
        }
    }
    static class BigCat extends Animal {
        @Override
        public String toString() {
            return "BigCat{}";
        }
    }
    static class Lion extends BigCat {
        @Override
        public String toString() {
            return "Lion{}";
        }
    }
    static class Tiger extends BigCat {
        @Override
        public String toString() {
            return "Tiger{}";
        }
    }

    static void f1(List<? extends BigCat> list) {
        System.out.println(list);
    }
    public static void main(String[] args) {
        List<BigCat> bigCats = List.of(new Lion(), new Tiger(), new BigCat());
        f1(bigCats); // COMPILES
        List<Lion> lions = List.of(new Lion(), new Lion(), new Lion());
        f1(lions); // COMPILES
        List<PussyCat> pussyCats = List.of(new PussyCat(), new PussyCat(), new PussyCat());
        f1(pussyCats); // DOES NOT COMPILE
    }

But when I block off the f1(pussyCats) call with the compiler error, it works as I expected.

Output:

[Lion{}, Tiger{}, BigCat{}]
[Lion{}, Lion{}, Lion{}]

[Anil Philip]

Paul Anilprem wrote:the compiler... has no idea about the actual object pointed to by the variable

Then we would never get compile time errors when we try to pass in, or assign the wrong type.

[Mike Simmons]

The compiler does have some idea, yes.  But it doesn't know the actual types that will occur.

It's probably best not to use the word "immutable" to refer to something like List<? extends BigCat>.  We use that term to refer to classes that enforce their unchanging nature more strictly.  This particular mechanism does encourage coders to treat the list as immutable, in that it becomes difficult to add anything to the lit.  But it has two big loopholes.  One, it can be defeated by casting the List to a raw type. That would generate a warning, which can also be disabled.  Two, the list might have been created as a mutable list outside this method, then now within this method it's being treated as "immutable" - but another thread could still have a reference to it as a List<BigCat>, and that other thread can change the items in the list even though it's not being changed in the method that uses List<? extends BigCat>.

Since there's already a lot of literature out there on what immutability is and how to achieve it in Java, I would avoid that term here.  The list in not immutable.  It's declared in a way that discourages us from changing it, but it doesn't guarantee that.

[Anil Philip]

Mike Simmons wrote:The compiler does have some idea, yes.  But it doesn't know the actual types that will occur.
It's probably best not to use the word "immutable" to refer to something like List<? extends BigCat>

Thank you for your reply.
What is "some idea" and "actual types"?
As in the example I gave (in reply to Henry Wong), if the actual datatype being passed in or assigned to, is a mismatch, it will complain without hesitation.
The term "immutable" is used in chapter 9 of the Boyarsky-Selikoff OCP-17 book to describe such a list.
Perhaps they should use "non-appendable list" or "size-frozen list" instead?

[Paul Clapham]

public void processList(List<? extends Player) list {
  // Code processing the list goes here
}

The compiler knows that a List will be passed to the parameter by the calling method. It also knows that it will be a List<X> where X is some subclass of Player. So it's accurate to say that the compiler has "some idea" of what type of list will be passed to this method. The "actual type" which is passed is known only to the caller.

[Anil Philip]

Paul Clapham wrote:The "actual type" which is passed is known only to the caller.

But the calling code is right there. :)
Even if it is a call into a library method, to my understanding, the types will be examined at compile time to see if the signatures match.

[Mike Simmons]

Anil Philip wrote:Even if it is a call into a library method, to my understanding, the types will be examined at compile time to see if the signatures match.

It will only be checked inside the new code that called it - it won't recompile the library method with information about its new callers.  With processList(List<? extends Player>), inside that method it knows only that the argument is a List of some type of Player.  That code might be compiled long before any outside code  tries to call it.  Maybe in one place, someone will call it with a List<CardPlayer>.    And in another place, someone might call it with a List<PokerPlayer> (a type of cardPlayer).   And somewhere else, they might call it with a List<BasketBallPlayer>, a different Player subtype which is unrelated to CardPlayer.  So, inside the processList() method, what do we know about the type of the list?  It could be any of those, or also any other type of List<? extends Player> which someone adds later on.  The actual types of the objects in the list will always be some type of Player (well, unless someone deliberately miscasts a raw type) but it may be something more specific, or not.

As for "immutable", yes I would say that it's wrong of them to use it in the book.  It just creates confusion here.

[Mike Simmons]

Paul Anilprem wrote:Generics is compile time magic only.

Well, it's compile-time magic that can also have an effect at runtime.  Which is true of most code, I suppose.  Generics are usually just compile-time in their effects, but sometimes those effects are deferred to later.  Consider something like this:

    List list = List.of("A", "B", 1, 2, 3);
    List<String> strings = list;
    System.out.println(strings);
    for (var s : strings) {
      System.out.println(s);
    }

At compile time it will issue a warning (which can be disabled or simply ignored)... it won't actually error until runtime.  And even then, perhaps later than you might have expected.

[Paul Clapham]

I know this is related to a certification exam so you don't really have to know anything about where you'd use this construction. But putting my psychologist hat on, it seems to me that under all of this discussion is the question, what the * do we need this for? What's the point of having this weird List where we can't even add anything to it?

Indeed, why do we need List<? extends BigCat>? Why not just use a List<BigCat> and be done with it? That would be much easier.

So here's an example of that:

    List<Lion> lions= List.of(new Lion(), new Lion()); // Here we've got a list of Lions.
    List<BigCat> cats = lions; // A Lion IS-A BigCat so we can put Lions into this list, right?

And better still we can now add entries to that list:

    cats.add(new Tiger());

But now we have a problem. There's only one List object, the two variables "lions" and "cats" both refer to it. So now that list has two Lions and one Tiger. That's bad because the "lions" variable is of type List<Lion> but the list it refers to now has a Tiger in it.

The problem comes from that assignment statement. Actually, it's illegal exactly because of this simple example. To make it legal you need List<? extends BigCat> instead. You can't add new entries to that list, so no chance of tigers in the lion cage.

[Anil Philip]

Mike Simmons wrote:

Anil Philip wrote:Even if it is a call into a library method, to my understanding, the types will be examined at compile time to see if the signatures match.

It will only be checked inside the new code that called it - it won't recompile the library method with information about its new callers.  With processList(List<? extends Player>), inside that method it knows only that the argument is a List of some type of Player.  That code might be compiled long before any outside code  tries to call it.  Maybe in one place, someone will call it with a List<CardPlayer>.    And in another place, someone might call it with a List<PokerPlayer> (a type of cardPlayer).   And somewhere else, they might call it with a List<BasketBallPlayer>, a different Player subtype which is unrelated to CardPlayer.  So, inside the processList() method, what do we know about the type of the list?  It could be any of those, or also any other type of List<? extends Player> which someone adds later on.  The actual types of the objects in the list will always be some type of Player (well, unless someone deliberately miscasts a raw type) but it may be something more specific, or not.

As for "immutable", yes I would say that it's wrong of them to use it in the book.  It just creates confusion here.

1) In the case of new code, the compiler will complain of an error.
2) In the case you pointed out, of code that is not recompiled,
the contract to the processList method is that of List<? extends Player>
Why should it matter to the processList method what specific subtype it is as long as it is a Player?
The subtypes can override methods in Player so that the method can invoke them and be oblivious to the actual type.
Which is why I was trying to understand what the issue is in allowing adds to the List as long as one is adding a kind of Player.

[Anil Philip]

Paul Clapham wrote:

    List<Lion> lions= List.of(new Lion(), new Lion()); // Here we've got a list of Lions.
    List<BigCat> cats = lions; // A Lion IS-A BigCat so we can put Lions into this list, right?

[code=java]  

Sorry but that is incorrect, from what I understand.
A List<Lion> is not a List<BigCat>
In fact those two lines of code do not compile at all.

[Paul Clapham]

Anil Philip wrote:Sorry but that is incorrect, from what I understand.
A List<Lion> is not a List<BigCat>

That's correct. That's why I said that in the post you're quoting from.

In fact those two lines of code do not compile at all.

The first line compiles. But the second doesn't, as I said in the post you're quoting from.

[Paul Clapham]

Anil Philip wrote:Which is why I was trying to understand what the issue is in allowing adds to the List as long as one is adding a kind of Player.

So now you should clearly understand why that is.

[Paul Anilprem]

Anil Philip wrote:

Paul Anilprem wrote:
Which exact subclass of BigCat, it doesn't know. Since the compiler has no information about the actual List,
.....
This is very different from List<? extends BigCats<). This is not a list of BigCats. It is a list of some specific (but unknown to compiler) subclass of BigCats.

<br />
The statements above are where I have the problem in understanding.
The compiler knows what you are adding to the list and whether it is a legal subtype.
Hence it should allow adds()

When the compiler sees

        List<? extends BigCat> list = new ArrayList<Lion>();

It should know this is a list of subtype Lion.
...

Your are talking about the technical feasibility of what all the compiler can know looking at the code. But it is not about that at all. Compiler doesn't care about actual object types at all. Looking at actual objects is squarely in the domain of the JVM. Objects are created at runtime and it is the JVM responsibility to make sure that the runtime remains type safe at all times. Compiler only goes by whatever information is present in the variable type. Compiler's objective is to prevent obvious coding mistakes and it does so by ensuring that the code is "reasonably" type safe. This is how the language designed. There is no other special logic in this.