3

Some threading problems were solved without extending java.lang.Object.

The methods wait(), notify() and notifyAll() are implemented on Object, which seems to me not to be the best decision since it pollutes the class's interface. It affects all classes in Java, which I think should have been avoided.

Next, the synchronized block takes an instance of type Object, allowing us to accidently pass shared instances (e.g. String), which can cause problems. They could have crafted a class Mutex/Lock in order to avoid this.

I wonder whether this comes with any technical advantages - e.g. performance - or whether it is just bad design? Is there somewhere an official documentation, e.g. a JEP or something similar - on why the Java language designers decided to work directly with java.lang.Object?

aboger
  • 2,214
  • 6
  • 33
  • 47
  • Why not ask the [OpenJDK devs](https://mail.openjdk.java.net/mailman/listinfo)? – Turing85 Aug 02 '20 at 16:14
  • 1
    Good idea. I think I'll drop a mail there if no answer will pop up here within some days. – aboger Aug 02 '20 at 16:18
  • @aboger What do you mean by "without extending `java.lang.Object`"? Every class extends from that class, it is not possible to **not** extend from that class. – Progman Aug 02 '20 at 16:20
  • 2
    @Program I mean, why does every class in Java implement e.g. `wait()`. Why isn't there a `class Mutex { public void wait(){} }`. Or why does `synchronized(a)` take an argument of type `Object`, not e.g. only instances of type `Mutex`. – aboger Aug 02 '20 at 16:24
  • 3
    I think that, in hindsight, the Java platform agrees this was unnecessary. Your `Mutex` class is called [`Condition`](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/Condition.html). It's an interesting question, but these "why are things this way" questions tend to invite speculation and opinion that isn't a good fit for stackoverflow. Software engineering might have place for them (I'm not as familiar with that site though). – erickson Aug 02 '20 at 16:27
  • 4
    I have a hard time to understand how asking for a reference to official documentation is opinion-based. – aboger Aug 02 '20 at 16:34
  • "**Questions asking us to** recommend or **find a** book, tool, software library, tutorial or other **off-site resource are off-topic** for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." [Emphasis added.] – erickson Aug 02 '20 at 17:33
  • I'll keep it in mind for future questions. Thanks for explaining and for the `Condition` reference. – aboger Aug 02 '20 at 18:11
  • 1
    at the time that this decision was made, java did not really follow a `JEP` process ([here is the first one](http://openjdk.java.net/jeps/1)) There were people from Sun that decided what will the language look like. Very smart people, but they could not figure it out all. IMHO: this was a slight mistake, just like `Cloneable` and `clone` in `java.lang.Object` – Eugene Aug 02 '20 at 19:08
  • 2
    It is easy to casually slap the "mistake" label on decisions of this sort -- far too easy. The question of "should every object have a monitor" is one that is full of subtle tradeoffs. The real value of asking such questions should not be to come to a "mistake or not" conclusion, but to understand what the _goals, priorities, and expectations_ were that would have led some of the best and brightest to make this particular choice in 1992. (You could ask the same of hashCode() -- but the pragmatism of this choice is far more obvious.) – Brian Goetz Aug 03 '20 at 16:52
  • Jeez... Brian Goetz commenting my question O_o amazing. I recently asked my teacher Heinz Kabutz this question and he gave me an answer similar to your comment, pointing out the _subtle tradoffs_, the different state of knowledge back then and more. Trying to get an insight into these tradeoffs, _the goals, priorities, and expectations_ of 1992 was exactly the reason for this question. I was hoping for a reference to some documentation on this to dig deeper, as it sounds really interesting. Well, given your comment, I now understand pragmatism as one design decision, thank you. – aboger Aug 03 '20 at 18:11

0 Answers0