Why is java not fully objective oriented?

plz answer my query.i want to know the cause why java is not fully object oriented language?
thnaks in advance

I guess java is fully object oriented.

No. Java is not considered 100% OO.
One argument is that Java uses primitive data types (like int, float etc), which are not objects. And in some languages even the control statements (if, while etc) are implemented as methods, which is an object oriented approach.

Mani,
This is an interesting train of thought. Tell me more. Why can't OO languages have primitives? And why should control statements be methods?
M

a "100% OO language" would ONLY have objects, by definition. therefore, since primitives are not objects, having them breaks the rule.
it's like saying "this bucket has 100% blue gumballs in it". if there is even 1 red gumball, the bucket is not 100% blue.
as for "ifs" and "whiles" as methods - i've never heard that before in the def of OO. But i also admit i'm not highly educated in such maters.

Originally posted by fred rosenberger:
a "100% OO language" would ONLY have objects, by definition. therefore, since primitives are not objects, having them breaks the rule.

Hi Fred. I'm aware of this statement: Alan Kay, the man who invented the term OO, has stated a similar opinion. However, I'm somewhat at a loss to understand it.
For example, integers are a primitives by definition only: they are still artificial data constructs offered by the language to encapsulate datum. True, they don't extend from the artificial construct which happens to be the java.lang.Object class, but I'm not aware that OO design requires that all objects in a language extend from a common base.
Perhaps it because they can hold data, yet are not subject to the normal object rules such as polymorphism. Of course, neither is the String class, as it's final.
All in all, I guess the argument that Java is not "100%" OO can be supported, but it seems somewhat to miss the point, IMO.
To be honest, the world has "100%" OO languages like smalltalk and Simula, but seems, by and large, to have passed on them. Perhaps that's because when we say "OO", what we really appreciate is Message Oriented Languages(MOP).
All best,
M

There's a lot of disagreement what 100% OO might mean. Alan Kay often says "C++ is not Object Oriented. I made up the term Object Oriented and C++ is not what I had in mind." He can probably say that about every other language. If you've done SmallTalk you know Java is nearly nothing like it. SmallTalk doesn't even have an "if" keyword. Sheesh.
If you find a language you like, can be productive with, can get paid for using, then just do it and smile a lot. Wondering what 100% OO means can be entertaining, but matters little in the long run.

I think James Gosling aim was create good language,
not 100% OO.
You can try to use instead int - Integer, float - Float, ...
to get the 100% OO language,
(and to slow down speed of your program)

I agree with Igor: By and large, the real test of OO-ness is support for polyMorphism, Inheritance, etc.
M

Originally posted by Stan James:
There's a lot of disagreement what 100% OO might mean. Alan Kay often says "C++ is not Object Oriented. I made up the term Object Oriented and C++ is not what I had in mind." He can probably say that about every other language. If you've done SmallTalk you know Java is nearly nothing like it. SmallTalk doesn't even have an "if" keyword. Sheesh.

As you mentioned, it doesn't matter much whether or not the tool is OO if it lets you get the job done effectively.
You are correct, there is no "if" keyword in Smalltalk. Control logic, including looping, is directly built into the class library itself. Both true and false are objects (singleton instances of True and False) that you can send messages. This plus the use of blocks or closures allows for control logic to be directly built into the class library instead of the language. It's a simple, elegant solution. Simplicity is a core value in Smalltalk; I can teach the syntax in about 15 minutes--the rest of your knowledge comes from the class library.
As different as the languages appear, Java has a lot in common with Smalltalk, one of the languages in which Gosling claims to have developed. On the surface, the syntax has many similarities to C++. However, much of the fundamental design of the language has more commonality with Smalltalk: using a VM to interpret byte codes, garbage collection, single inheritance, an inheritance hierarchy stemming from Object, class objects (sort of), virtual methods by default.
Smalltalk is more or less dead. I harbor no illusions that it was a "better" language because it was pure OO. But the reason it died had nothing to do with its OO-ness. Or even with its performance due to such--in fact, when Java first came out, it was several times slower than Smalltalk. The only opinion I'll put forth about Smalltalk vs. Java is that I dearly miss programming in Smalltalk; it was a lot more enjoyable and a lot easier than programming in Java. Java is OK in comparison.
-Jeff-
[ February 25, 2004: Message edited by: Jeff Langr ]

Well this is more a matter of definition, I feel, than anything else, though it's a definition I'm comfortable with. Java is not 100% OO because it allows primitive types. It's important when discussing this to dispassionately treat this sort of statement as a simple statement of fact and assume it places any value judgment on the language...it doesn't mean Java's good or bad, just that it doesn't follow the 100% OO model, that's all.
In my mind, speaking purely about semantics, these kinds of characterizations of languages can be placed on a spectrum from the OO side to the procedural-oriented side. C falls way on the POP side, C++ in the middle, and Java about 3/4ths of the way to the OOP side. Does SmallTalk peg the OOP-extreme side? I don't think so--as long as there are keywords in the language, those keywords don't represent themselves as objects to the compiler and runtime system, but they sure do represent something, so it's not totally OOP either (from a purely semantic standpoint). If we take the most extreme view of OOP and POP in order to make sure our spectrum has a spot for every conceivable language theoretically constructable, you arrive at the notion that a truly 100% OO language would have to be completely written indirectly through a meta-language that did allow every element of the language itself to remain "pure object". In this way the manifestations for controlling branching and such structures would be objects themselves and totally extensible, blah blah blah.
Not very useful, though. Again, I think it's important to avoid the semantic discussion of "is this x% OO?" and instead just stick to assessing OO through comparison. You avoid semantics that way and stick to the issues that contribute to a langauage's OO-ness or detract. If I say, "Is Java's treatment of Strings OO?" we could get into a long, drawn-out discussion with many valid viewpoints. But if I ask a slightly different question, "Is Java's treatment of Strings more or less OO than C++'s? SmallTalk's?" now we can have a useful discussion that contributes to understanding of what it means for a language to be "OO".
Oh, on the same topic, I thought I'd point this out...I feel that the JavaBeans spec makes a huge error in the quest for OO-ness by defining setters as a core piece of a JavaBean. A setter, to me, is nothing more than just another operation on a class, and I have no compunctions whatsoever about including set operations for variables in other contexts. Getters are pure, in my mind, and more than that, they do deserve special conventions that set them apart from other methods (the getXxx() naming) because you can (ideally) define all of a class' behaviors in terms of its getters.
But consider this case...let's say you are writing a class that has two internal bits of data, and they only make sense if they are both set, or neither. For example, an UserInfo class that has both a username and password. Any attempt to set one without the other, for this application, should result in an exception being thrown, let's say. If you follow the normal JavaBeans getters and setters, how do you write this? You can't write a setter for each property, username and password, because that allows the caller to set one and not the other. In fact, it's required to let the user set one and not the other, at least for a moment...otherwise, how does the user ever set both?
// the JavaBeans--and IMHO, incorrect--way of doing things public class UserInfo { private String username; private String password; public String getUsername() { return username; } public void setUsername( String un ) { username = un; } public String getPassword() { return password; } public void setPassword( String pw ) { password = pw; } }
Where do you write the code that ensures one is not set without the other being set to a non-null value? Can't be done inside the class itself following JavaBeans. Now consider the other way:
// a better way... public class UserInfo { private String username; private String password; public String getUsername() { return username; } public String getPassword() { return password; } public void setInfo( String un, String pw ) { if( un == null ^ pw == null ) { // only one is non-null--throw exception } username = un; password = pw; } }
This is why I think the special recognition given to setters by JavaBeans is not really an advance in helping along the OO usage of Java.
sev
[ February 25, 2004: Message edited by: sever oon ]
[ February 25, 2004: Message edited by: sever oon ]
[ February 25, 2004: Message edited by: sever oon ]

out of the blue . . smalltalk