Is Java 100% object oriented? [closed]

Answer 1

This is one of those questions that really only matters in an academic sense. Ruby is optimized to treat ints, longs, etc. as primitives whenever possible. Java just made this explicit. If Java had primitives be objects, there would be IntPrimitive, LongPrimitive, etc (by whatever name) classes. which would most likely be final without special methods (e.g. no IntPrimitive.factorial). Which would mean for most purposes they would be primitives.

Answer 2

When Java first appeared (versions 1.x) the JVM was really, really slow. Not implementing primitives as first-class objects was a compromise they had taken for speed purposes, although I think in the long run it was a really bad decision.

"Object oriented" also means lots of things for lots of people. You can have class-based OO (C++, Java, C#), or you can have prototype-based OO (Javascript, Lua).

100% object oriented doesn't mean much, really. Ruby also has problems that you'll encounter from time to time.

What bothers me about Java is that it doesn't provide the means to abstract ideas efficiently, to extend the language where it has problems. And whenever this issue was raised (see Guy Steele's "Growing a Language") the "oh noes, but what about Joe Sixpack?" argument is given. Even if you design a language that prevents shooting yourself in the foot, there's a difference between accidental complexity and real complexity (see No Silver Bullet) and mediocre developers will always find creative ways to shoot themselves.

For example Perl 5 is not object-oriented, but it is extensible enough that it allows Moose, an object system that allows very advanced techniques for dealing with the complexity of OO. And syntactic sugar is no problem.

Answer 3

One reason Java can't obviously do away with non-object primitives (int, etc.) is that it does not support native data members. Imagine:

class int extends object
{
    // need some data member here.  but what type?
    public native int();
    public native int plus(int x);
    // several more non-mutating methods
};

On second thoughts, we know Java maintains internal data per object (locks, etc.). Maybe we could define class int with no data members, but with native methods that manipulate this internal data.

Remaining issues: Constants -- but these can be dealt with similarly to strings. Operators are just syntactical sugar and + and would be mapped do the plus method at compile time, although we need to be careful that int.plus(float) returns float as does float.plus(int), and so on.

Ultimately I think the justification for primitives is efficiency: the static analysis needed to determine that an int object can be treated purely as JVM integer value may have been considered too big a problem when the language was designed.

Answer 4

According to Concepts in Programming Languages book, there is something called Ingalls test, proposed by Dan Ingalls a leader of the Smalltalk group. That is:

Can you define a new kind of integer, put your new integers into rectangles (which are already part of the window system), ask the system to blacken a rectangle, and have everything work?

And again according to the book Smalltalk passes this test but C++ and Java do not. Unfortunately book is not available online but here are some supporting slides (slide 33 answers your question).

Answer 5

No. Javascript, for example, is.

What would those Integer and Long and Boolean classes be written in? How would you write an ArrayList or HashMap without primitive arrays?

Answer 6

Java is not 100% OO. Java may going towards 99% OO (think of auto-boxing, Scala). I would say Java is now 87% OO.

Why java doesn't design primitive data types as object way ?

Back in the 90's there were Performance reasons and at the same time Java stays backward compatible. So they cannot take them out.