Is Java Object Oriented

"Is Java a true "Object Oriented" language?"

[From ObjectOrientedProgramming, and JavaLostEnumeratedTypes.]

[See also "JavaDesignFlaws" for other negative comments about the Java language. (But try not to get too hot under the collar. ;-) ]

JamesGosling and HenryMcGilton? think it is. They explain many of Java's features (in particular it's Object Orientedness) in their whitepaper: http://java.sun.com/docs/white/langenv/Object.doc1

The talk below is rather outdated. Java 1.5 introduced enumerated types.

That said, Java is not a pure Object-Oriented language. Someone said Java is a hybrid, which, IMO, is an accurate description. I would posit Java is a dirty hybrid of an OO language. Consider:

String s = string2.trim();

First, since "String" is immutable, the above code reeks of functional programming. The "trim()" operation should cause the whitespace to be trimmed off both ends of "string2", without needing reassignment. That is to say, operations should act on the data as close to the object as possible. This, to me, makes Java feel dirty (it also leads to tightly-coupled systems due to the prevalence of "get" accessor methods, but that's another topic entirely). Ahem, what? That example is perfectly OO. Object-orientation does not make mutable state necessary. Actually, since strings are passed around so often, the lack of mutator methods really just saves a lot of headache.

Second, Java cannot alter the behaviour of all messages. It mixes the types of "operations" available to objects, depending on their type. The "+" is equally applicable to ints as it is Strings, but not to Matrices, or Colors. This isn't so bad, because you can do matrix.add( matrix ), but serves to illustrate the point about Java being 'dirty' (or 'impure', if you prefer).

Lastly, it is a hybrid to provide performance gains. Even though Smalltalk has an advanced virtual machine, its inability (when I was using it) to provide a machine-correlated bytecode for integer math placed a significant performance impact on its entire environment. Being a hybrid, Java cannot be called a true Object-Oriented language. But then, why does it matter? ;-) Use the right tool for the job and life will be happy!

The fact that Java does not have EnumeratedTypes is not a design flaw. It is just a side effect of the decision to make Java an object oriented language. -- MichaelFeathers, originally on JavaLostEnumeratedTypes

Well, you can certainly do object-oriented programming in Java, but that doesn't make Java object-oriented. If the language itself were object-oriented, there would be no distinction between primitive types and objects for instance, amongst other things.

I also disagree, Java is a hybrid. If it really was an object-oriented language, we would be able to do things like the SmallTalk:

  1 to: 6 do: [:index | getOnWithIt: index ]

I think the real reasons that Java does not have enumerations are:

(official) Java is designed for dynamic loading, so you don't want to lock down things like enumerations
(alternate official version) We didn't like the way enums are implemented in C and wanted to do it "right", but didn't have the time to find out what "right" would mean. (Obviously they now did, as enums were introduced with Java 5, and are much more powerful than their C counterparts.)
(unofficial) Um, we didn't quite get to that bit in time...
(legacy-related) Enumerations would look weird to the C++ites that Java wanted to attract - it's a difficult thing to get into C-syntax.

It could just be the OO thing. What good is an enumeration if you don't switch on it? Switching on a code is pretty sad in OO.

If I have a mechanical pacemaker am I not still a biological being? Just because Java is not pure OO doesn't mean it isn't OO. -- DefenderOfTheJust?

I think it's ultimately a mistake to speak of a language as "being OO" or "not being OO". A language can support OO by including language features that make it easy to implement. But you can write functional code, or structured code, or heaping plates of spaghetti code in any language.

And there are plenty of other dimensions to programming languages: generics, for example. If a language pays some attention to those aspects, does that make it any less OO? Does that make it any more difficult to write OO code in it? No.

-- GeorgePaci

Java is not an object-oriented programming language. If it were, all its primitives would be objects. It moves half-way in this direction with String (and perhaps Array), but it doesn't quite go far enough. Actually, one could argue that as String and Array aren't subclassable, that makes those parts of Java at best object-based.

For a language to be object-oriented, it does really, actually, totally mean that all the first-class constructs must be object-oriented. Whether you can do objects with the language is not relevant. You can make objects in LISP and Scheme, not to mention Perl, and neither of those languages are object-oriented. Further, you can make objects in Self, but Self isn't object-oriented (it's prototype-based, which is "more object-oriented").

Sidelining this on some weak "let's all get along" anti-ReligiousWar love-in is all well and fine if we were in the middle of a ReligiousWar, but from a technical, language theoretic point of view, Java is not object-oriented and neither is C++. So, get over it already. Go outside and hack some code. -- SunirShah

What is an object-oriented language? Here, you say that all first-class constructs must be object-oriented? If you define oo language like that, java is not object oriented. ObjectOrientedProgramming says something completely different. And according to this site, I think Java is an OOP Language. Personally, I would say that java is an object oriented language -- ThomasHolenstein?

I'm not going to repeat myself unnecessarily. Please read my comment again to understand the difference between an object-oriented language and programming object-oriented. If you have specific objections or questions, though, I'll happily respond to them. By the way, SmallTalk is an object-oriented language. -- SunirShah

No, that's the pure OO argument. In pure OO (e.g. SmallTalk, Eiffel), all types are objects and all code is method code. Java isn't pure OO because some types aren't objects. C++ is even less pure, because some code isn't method code. But Java and C++ are still OO because they provide capabilities such as encapsulation, inheritance, polymorphism, abstract data types, classes, ... . See ObjectOrientedProgramming for the over-full list. They are OO - not pure OO, but hybrid OO.

And does having a pure OO language really enforce OO programming? I'm sure you can write non-OO programs in SmallTalk if you feel sufficiently masochistic. You can in Java. Just instantiate one object with lots of instance variables and lots of methods with lots of local variables. -- MattRickard

It doesn't matter what you can or cannot program in the language; a language is object-oriented if and only if all its first class constructs are object-oriented (with some looseness for object-based constructs for approximate discussion, I suppose). You can write objects in LISP, but that doesn't make LISP object-oriented--it is functional. In fact, LISP is much, much, much more powerful than object-oriented. There's no point in arguing that Java is object-oriented because it technically isn't. This does not mean that you cannot write object-oriented programs in Java. What it does mean, from a practical point of view, is that it is more complicated to write object-oriented programs in Java than SmallTalk. It's also more complicated to write structured programs in SmallTalk rather than Pascal. And it's harder to write structured programs in Java than Pascal as well. This is all above. What part isn't clear?

[Later...] Running through the literature, I understand what you mean about the "pure OO argument." Ok, granted, after C++, people had adopted the qualifiers "hybrid" and "pure". But since this page is related to JavaDesignFlaws, the point is that there are non-OO constructs in Java because at a very basic level, Java is not OO. In fact, most of Java is structured--all those bits inside the methods. This was a conscious choice of the Java designers, and not necessarily a design flaw. More like a design principle. So, no, Java is not an object-oriented language, but it certainly encourages OO at a very high level. Though you must grant that at a low level it is not really object-oriented.

Given that, do structured principles fit into Java? Or is Java just ultimately hosed, being a bastard child of two philosophies? -- SunirShah

In Java you just abuse the static keyword for methods.

To create structured code? True, but that isn't really the point. What's inside those methods?

IMHO, Java's concept of a class is what really breaks the OO-ness. In Java, a class is not an object, it is a namespace for static methods. To treat it like a class object, you write ClassName.class. However, you can't write this:

     class C {
         public int i;
         public C(int i) {this.i=i}
         public static void foo() {print("Hello, world!");}
     }
     class Bar {
         static void doFoo(??? o) { // insert hackish typing workaround here.
              o.foo()
         }
         public static void main(string[] args) {
              this.doFoo(C) // can't use this in a static method.
         }
     }

Thus, in Java, classes are NOT first-class citizens. You can't treat them like they are objects, even within static method definitions. You can't have metaclasses.

On the other hand, the following is perfectly valid Scala:

     trait Fooable {
         def foo() : Unit
     }
     case class C(i : Int)
     object C extends Fooable { // Classes are objects: right there in the syntax.
         def foo = print "Hello, world!"
     }
     object Bar {
         def doFoo(o : Fooable) : Unit { // Metaclasses: OK.
              o.foo()
         }
         def main(args : Array[String]) : Unit = {
              this.doFoo(C) // this: OK.
         }
     }

On translating that code back to Java, one will find that there are actually a ton of workarounds used to get JVM code to accept this stuff. However, Scala itself never lets you see that there is anything behind the abstraction, while Java...does.

Scala also treats its Ints as real objects; using primitives at runtime is an optimization which you don't have to think about. (I think that they're still not nullable, but Scala being Scala, that's just some clever tricks in the typesystem. Even if the fact that Ints aren't nullable is an optimization, it's at least a well defined, formalized one. You can still call methods on 'em, in any case.)

Hmmm... "a language is object-oriented if and only if all its FirstClass constructs are object-oriented"... By this definition, I would certainly call Java object-oriented; as I understand the relevant terms, its primitive types are second-class constructs. (Some reading on FirstClassness: http://compilers.iecc.com/comparch/article/92-03-045.)

How is a primitive not a first-class construct?

Java's primitive types are second-class citizens in that the operations which are otherwise available on all types do not apply to them. You cannot instantiate an int, invoke a method on it, use instanceof to determine its runtime type, and so on. Similarly, Java arrays are second-class citizens in that they cannot be subclassed or methods invoked on them.

Of course, my assertion that in Java, objects - instances of classes - are FirstClass constructs is tainted by my admitted bias in thinking of Java as an OO language. They are undoubtedly in a category of entities distinct from the primitive types, which is also distinct from the category to which arrays belong. I am only distinguishing them as "first" class because I happen to believe that Java is a fair approximation of OO ideals, though I would willingly concede that it doesn't hold a candle to SmallTalk.

All of the foregoing assumes that I am not just spouting nonsense when I use technical terms such as FirstClass, which as usual may turn out to be an unwarranted assumption.

Look at the question another way. Assuming one can agree on the characteristic benefits of OO, can those benefits be obtained by programming in Java. In short, yes. Therefore Java is OO.

This has turned into less of a discussion about whether or not Java is OO and more about what the actual definition of OO is. There is also the notion of ObjectOrientedProgramming versus an ObjectOrientedLanguage, the two not necessarily being the same. We really need to agree on a definition (informal UnitTest) before being able to say whether or not a language (or practice) conforms to it.

[Definition attempts moved to ObjectOrientedLanguage]

This discussion is a shame. Java IS OO, and C++ is OO, and Eiffel is OO, and Smalltalk is OO, and Common Lisp is OO, and Ada 95 is OO, and ObjectPascal is OO, and anyone can add here. You can also discuss Java shortcomings, or Java trade-offs, and the same about other programming languages.

: You don't happen to know a non-OO language, do you? I mean, there are those Perlites who attach a namespace to any old scalar and call it an object. So surely Perl IS OO. And there's Glib, which is pure C and uses composition instead of inheritance. So what, it's ugly, but it means C IS OO. Lexical closures behave like Objectsm therefore Scheme IS OO. See the pattern? But if everything IS OO, the term is meaningless. (And I definitely agree on that.)

No, Java supports OO, and C++ supports OO, and Eiffel is OO, and Smalltalk is OO, and Common Lisp supports OO. There is value in making the distinction between a language that can do something, and a language that must do something. In Java, an int doesn't have to be an object, in Smalltalk it does. Therefore, Smalltalk is OO, Java can be OO. It's not dissing Java, it's making a distinction between a language that forces OO, from one that just supports it. That distinction is there, whether you like it or not, so you may as well recognize it.

The problem is that some folks place value judgements on the "pure OO" vs "supports OO" dichotomy. The SmalltalkLanguage community is especially notorious for this. :) Now, there may be legimitate reasons why Smalltalk rules and Java sucks, but IMHO this isn't one of them. One could easily argue (if one is a MultiParadigmWeenie) that multi-paradigm languages like CommonLisp, OzLanguage, OcamlLanguage are superior to pure-OO languages (with CeePlusPlus being the exception that proves the rule, obviously). However, like all judgments on programming language quality; such a blanket statement begs a whole host of questions.
- Speaking as a C++ programmer, C++ is multi-paradigm the same way that a 2-legged dog is multi-legged.
The problem is that some folks place value judgements on the "pure OO" vs "supports OO" dichotomy. The SmalltalkLanguage community is especially notorious for this. :) Now, there may be legimitate reasons why Smalltalk rules and Java sucks, but IMHO this isn't one of them.

Well, to an OO programmer, this is one of them. Whether you think it is or not, it is to them. Being forced to use simple types, that aren't objects is a pain in the ass in Java and is responsible for much ugly code, so it is a big deal if you are trying to do OO. The capabilities of Java vs the capabilities of Smalltalk as a language are vastly different, and much of this is due to Smalltalks insistence on pure OO, and you'd have to know Smalltalk to understand that difference, someone who just knows Java won't grasp it, they're the Blub programmer from the Smalltalkers point of view.

What about SmalltalkLanguage, vs, say, CommonLisp? (The SmugWeenie? grudge match of the century!)

Interesting question, my answer would be they took different approaches to solve the same basic problem. Lispers use macros to hide the ugliness of lambdas behind sweeter syntax. Smalltalkers just gave lambdas a sweet syntax -> []. Both languages heavily use HigherOrderFunctions and can build mini languages. I tend to see both sharing the title as the most powerful language equally, what do you think?

While Java isn't a 100% pure OO language; it is object-biased--it certainly isn't a MultiParadigmLanguage. At any rate, the list of Java's sins extends well beyond int not being an object.Actually, C++ is better in this regard in that non-objects and objects are at least on equal footing; whereas the intrinsics in Java are crippled in many respects. (C++, of course, has a multitude of other sins to answer for).

And the assertion that Smalltalk "forces" OO is a little bit, shall we say, exaggerated. Smalltalk cannot force anybody to program OO just like Smalltalk cannot force anybody to write good programs.
- Interesting point. Obviously it can't force good OO programs, but just how non-OO could you manage in Smalltalk? Have a handy example?
- Can you write a Scheme interpreter in Smalltalk? Sure you can. Then the sky's the limit.

Who ever started to pretend monopoly for OO definitions? Were those Smalltalk fans or Eiffel fans? Do we need a FanClub? here, really?

This is just ridiculous. Please stop this.

I Agree! I am reading ObjectOrientedSoftwareConstruction right now and I is really hard to stomach because of this ObjectPurism business pervades the book to such a great extent. According to the book my language is a worhless dog and should just be put down. But even BertrandMeyer the author of this book, has some good things to say about Java.

Even though the discussion is ridiculous, it helps people who are in confusion to know what is OO and what is pure OO, and C++, Java and Smalltalk fits into. Thanks for all the contributors. -- NageshReddy?(NageshDeveloper?@RediffMail?.com)

Here's my test of "OO-ness":

One of the more subtle sources of error is confusion over units of measure. I write something in gallons and somebody else reads it as liters. The OO solution to that is measurement classes to provide type safety, e.g. Weight. The internal value is just a float, and all the needed operations match the operations on a float. High OO-ness belongs to the languages that let me define a Weight class, without having to write methods for all the aritmetic and relation operators, that makes code like the following valid:

  a = Weight.Grains(158);
  b = Weight.Stones(8);
  Weight c = a+b;
  print("Ted with bullet weighs ", c.pounds, " pounds.");

Also, rather than an untyped math library in a static class pretending to be an object, high OO-ness requires:

  sin30 = (Angle.Degrees(30)).sin;

-- MarcThibault

That's the "OOP is about types" view of OOP. Others feel it's more about the structure of code, not so much type safety and "fancy" types. But, NobodyAgreesOnWhatOoIs. Note that above in "c = a+b", what decides which object "+" belongs with? This is something that's odd about OOP and infix notation.

See DefinitionsForOo