Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Recently at a job interview I was asked "Is Java a "completely" object-oriented language?"
As I was completely unable to answer that question and do not know the answer, could someone, please, help me to understand the nature of this question.
As I see the question is being closed as "opinion-based" that's not an opinion I'm asking. I'm asking if I am unaware of that completely/incompletely category.
Kindly tell me if that's a wrong forum to ask this.
Java has primitives. Primitives are not Objects.
Depends on how you look at it, but yes, as #biziclop said, it's a matter of opinion.
To break it down, Java is, as you know, an object oriented language, but it's still possible to do functional programming in it (a static method that takes a primitive argument and returns a result).
Since primitives are not objects you can do non-object programming with Java.
So technically, no, Java is not a completely object-oriented language.
No. Java is not because it supports Primitive datatype[^] such as int, byte, long... etc, to be used, which are not objects.
There are seven qualities to be satisfied for a programming language to be pure Object Oriented. They are:
Encapsulation/Data Hiding
Inheritance
Polymorphism
Abstraction
All predefined types are objects
All operations are performed by sending messages to objects
All user defined types are objects
well Java is not 100% object oriented, because it still contains Primitive datatype
for example:
int i=0;
here i is not an object but contains the actual value.
However,
Set<String> set=new HashSet<String>();
set is a refrence that referes to a HashSet
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Why does Java not support a nice and readable direct print-out for arrays?
I do know that Arrays.toString can be used to get that, and I also know what the hashcode output means (as explained in Why does the toString method in java not seem to work for an array).
But I am asking myself why the developers did not choose to make arrays directly print the readable representation.
Is it technically impossible? Would it impact performance?
arrays in java are a special case. There is no java source code for an array class and arrays are implemented in the JVM directly.
Given that, arrays don't have any methods themselves and they do not override any of the default Object methods (Yeah they're treated as objects but they're handled with special bytecodes).
As for why the decided to do that it probably has to do with allowing more flexibility with creating arrays of different types and dimensions, maybe processing speed as well.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have researched a little bit about the Object class but don't have an explicit answer to my questions (mostly documentations on the class members).
What is the benefit of having an "object" class at the root of the class hierarchy and basically why does a class has such an Object?
My guess is, because java is a strongly object oriented programming language and having an "object" at the root would be ideal to this concept. Doesn't coupling increase every time we inherit further from the root?
Well the benefit is, that everything (except primitives) are an Object. So there are certain things you can do with every Object, like synchronizing on it, or comparing two of them for equality or converting one to a String.
Of course this could just work by some kind of build in language feature. But in OO there is already a feature for that: inheritance, so it makes the language simpler by using this concept.
Of course one can have lengthy discussions, about each and every method of Object, if it was a good idea to include it.
So that all objects can inherit the basic methods from the main Objects class and you have the option to override them. Ex. toString();
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I referred a tutorial app from Google playstore named AllTech where it is said that java is not a fully object oriented language as it is using PRIMITIVE TYPE.
I would like to know why it is not fully object oriented language as it is using primitive type. Every object oriented language would have primitive type.
So what a language needs to have to be fully object oriented language?
Thanks for your valuable time for looking into this.
Encapsulation.
Inheritance.
Polymorphisim.
Abstraction.
If the language has these attributes, then it can be used to do "full" object-oriented programming.
In Java, primitives are not objects. It was a conscious design decision in order to improve performance aspects. For example, there is no abstration around an int, nor can you inherit from an int and an int doesn't encapsulate anything (not even the number of bits it contains), nor can an int be polymorphic (although the compiler "helps" out to some degree with auto-boxing and promotion).
So, in some ways a language needs some things to be fully object-oriented, but in other ways it needs to lack some things in order to be only object-oriented. Java is fully object-oriented, but it also has primitives. If it lacked them, then it would be only object-oriented.
People start off learning Java in a hybrid mixed-mode. They learn to use objects and primitives together. This has some advantages and some risks. The risks are that they might program without embracing an object-oriented point of view. The advantages are that they can leverage the more familiar iterative programming paradigm while they are learning object-orientation.
Real programs rarely get to adhere to only one paradigm over another, but when they do, often they see advantages due to not having to deal with the problematic bits when two approaches collide.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I think I have read some relevant discussions about Java is going to unify primitive and object data types.
Does anyone know the progress? Is it possible at all? I mean you can still keep the benefits of primitive data types after the unification?
Update:
A relevant discussion is here: no more primitive data types in Java (JDK 10+). What do you think?
Scala is the current answer for having a richer type system like this.
Note that primitives are not nullable and have a default value of zero, while objects have a default value of null. How would your code break if some values were neither true or false, but null instead?
It seems to me primitives would just be translated into objects behind the scenes, perhaps by the compiler, although older byte-code would have to still be supported. We wouldn't be able to go the other way due to nulls. For example:
int x;
Would be interpreted as:
Integer x = new Integer(0);
Functionality is sort of in place to do some of this automaticallyy. Right now you can do:
Integer x = 0;
This is the "autoboxing" functionality that was recently introduced.
I'm personally not all that thrilled by this if that's the approach. It will just reduce some syntactic sugar. It would also potentially result in collisions:
void myFunc(Integer i) { ; }
void myFunc(int I) { ; }
I guess they could wrap primitives into something that extends Integer to avoid this, but that seems even more complicated.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Is there a reason for some wrapper classes to have the same name as primitives with different case (i.e. boolean/Boolean), and some not (i.e. int/Integer)?
I don't want opinions, but knowing if the cause is based on a relevant design decision for what seems to be an inconsistency.
It's likely because Java was created to attract C/C++ developers.
int was from C++, which took it from C.
boolean as opposed to pre-C99 typedef'd bool was first used in ALGOL 60. C++ has a separate data type called bool. I don't think ALGOL 60 actually had the name boolean however. It is named after George Boole, who first defined an algebraic system of logic in the mid 19th century.
As far as why the autoboxed Class name vs the primitive name, well the primitive name already existed like I described. Since you would likely have a confusing time telling the different between int and Int in code, it was made more explicit. In Java, by convention, class names are in CamelCase. Thus, Integer is spelled out and capitalized.