I'll say this. There is more than one side to "object orientation".
A better comparison would be between the AS/400 architecture and Microsoft's COM. That is, you can write COM components just fine in C as long as you speak Hungarian. This kind of system extends "objects" across space (distributed, across address spaces, between libraries and application) and time (persistence) and the important thing is, I think, the infrastructure to do that and not particular ideas such as inheritance.
When I started coding Java in 1995 (before 1.0) it was pretty obvious that you could build frameworks that could that kind of extension over space and time and I did a lot of thinking about how you'd build a database that was built to support an OO language. Remember serialization didn't come along until Java 1.1 and than an RMI were still really bad and really cool ideas built on top of them often went nowhere, see
there was the CORBA fiasco too. What's funny is that it just took years to build systems that expressed that potential and most of them are pretty lightweight like what Hazelcast used to be (distributed data structures like IBM's 1990s coupling facility but so easy... Not knocking the current Hazelcast, you can probably do what I used to with it but I know they've added a lot of new stuff to it that I've never used) Or the whole Jackson thing where you can turn objects to JSON without a lot of ceremony.
The more I think about it, objects have different amounts of "reification". A Java object has an 8-16 byte header to support garbage collection, locks and all sort of stuff. That's an awful lot of overhead for a small object like a complex number type so they are doing all the work on value types to make a smaller kind of object. If objects are going to live a bigger life across space and time those objects could get further reification, adding what it takes to support that lifetime.
I worked on something in Python that brought together the worlds of MOF, OWL and Python that was similar to the meta-object facility
where there is a concept of classes and instances that build on top of the base language so you can more or less work with meta-objects as if they were Python objects but with all sorts of additional affordances.
A better comparison would be between the AS/400 architecture and Microsoft's COM. That is, you can write COM components just fine in C as long as you speak Hungarian. This kind of system extends "objects" across space (distributed, across address spaces, between libraries and application) and time (persistence) and the important thing is, I think, the infrastructure to do that and not particular ideas such as inheritance.
When I started coding Java in 1995 (before 1.0) it was pretty obvious that you could build frameworks that could that kind of extension over space and time and I did a lot of thinking about how you'd build a database that was built to support an OO language. Remember serialization didn't come along until Java 1.1 and than an RMI were still really bad and really cool ideas built on top of them often went nowhere, see
https://en.wikipedia.org/wiki/Tuple_space#JavaSpaces
there was the CORBA fiasco too. What's funny is that it just took years to build systems that expressed that potential and most of them are pretty lightweight like what Hazelcast used to be (distributed data structures like IBM's 1990s coupling facility but so easy... Not knocking the current Hazelcast, you can probably do what I used to with it but I know they've added a lot of new stuff to it that I've never used) Or the whole Jackson thing where you can turn objects to JSON without a lot of ceremony.
The more I think about it, objects have different amounts of "reification". A Java object has an 8-16 byte header to support garbage collection, locks and all sort of stuff. That's an awful lot of overhead for a small object like a complex number type so they are doing all the work on value types to make a smaller kind of object. If objects are going to live a bigger life across space and time those objects could get further reification, adding what it takes to support that lifetime.
I worked on something in Python that brought together the worlds of MOF, OWL and Python that was similar to the meta-object facility
https://ai.eecs.umich.edu//people/dreeves/misc/lispdoc/mop/i...
where there is a concept of classes and instances that build on top of the base language so you can more or less work with meta-objects as if they were Python objects but with all sorts of additional affordances.