Inheritance instance variables with Java

Question

I am aware that if you subclass a class (superclass) which has for example an instance variable, it is going to be inherited in the subclass.

i.e. :

class Weather {
    int humidity;
}

public class Rainy extends Weather {
    void changeHumidity() {
        humidity = 10;
        System.out.println(super.humidity);
    }

    public static void main(String[] args) {
        new Rainy().changeHumidity();
    }
}

Bottom line: I would like to know why the instance variable "humidity" gets shared between subclass and class.

I am aware that if I shadowed that, it would not be shared but still why another instance (even though is the superclass) should share a variable with the subclass in the inheritance logic.

Thanks in advance.

Answer 1

There were two decisions the creators of Java took that guided how they designed Java. One was that performance was a priority, it must not be judged unusable due to being too slow. The other decision was that they would target C and C++ developers, and make Java similar to what they were used to in order to make adoption easier.

So Java got public, private, and protected access like C++. Where package-private came in and why it is the default is not clear. They might have assumed developers would want to access variables directly in order to save on method call overhead. A long time ago I was working on a project with professional services people from Marimba, and we had the opportunity to investigate some of the implementation code, which was written with a lot of package-private members. When I asked why the explanation was it was for performance. This was before optimizations like JIT, so there may have been a concern that using accessor methods to get to frequently used superclass members might be too slow. On the other hand it might have been a style preference or they were using a freer approach as part of an evolving design, and maybe the idea behind making package-private the default was that this kind of freedom should be expected. (It's not something that has caught on judging by any other code I've read.) It was code written by Jonathon Payne and Arthur Van Hoff, so the professional service people may not have been in on the real reasons.

There's an interview where James Gosling talks about his reasons:

... one of the things that I had wanted to do early on was formalize setting and getting something in the language. You know how in JavaBeans there's this sort of convention that you write setter and getter methods? But I did a bunch of surveys of developers at the time, about whether or not they would like this to be there. And the average person went, "Oh my God!"

And so I didn't do it. But I think in retrospect, I should never have listened to them. I should have just done it. Because, I mean Beans basically layered on this facility that I had wanted to do anyway, but Beans did it as kind of an afterthought.

And because it's layered on as a naming convention, there's some things that don't fit together real well. And so, for instance, it would've made a lot of sense for the default protection for an instance variable to be private. And then the getters and setters, which the system would've known about at a much deeper level, to make them either public or package.

The direction in which the style has evolved has been to prefer making instance variables private, and expose them through getters if required. You can specify the private access modifier, like this:

private int humidity;

and then the variable won't be visible to the subclass.