Is Java really a purely object-oriented language?

This article by the Code Rural network –dee1024 original translation, reproduced please see the text at the end of the reprint requirements, welcome to participate in our paid contribution program!

Is java--really "object-oriented"? Let's go deep into the Java world and try to prove it.

In my first few years of learning Java, I learned from the book that Java follows the object-oriented programming paradigm (oriented programming paradigm). In the Java World everything is objects, even strings (string) These are objects (in C, strings are character arrays), then I think Java is an object-oriented language.

But later on, I saw a lot of developers on the internet site saying, "Java is not really a purely object-oriented, because not everything is an object in the Java world." Many of their arguments can be summed up in the following two points:

• All static content (static key-modified variables and methods) does not belong to any object, so these are non-object things.
• All basic types (char,boolean,byte,short,int,long,float,double) are not objects, because we cannot do things like normal objects (for example: using "." To access the properties and methods of the object).

At that time, because of the limited personal knowledge and experience, I was quite confident in the above argument, and began to think that "Java is not a purely object-oriented programming language."

And then, in my first JVM learning process, I had a new discovery:

When the JVM creates the object, it actually creates two objects:

• One is an instance object.
• The other is a class object. The class object is loaded only once within the JVM, and the static and static properties of the class are loaded together, and the JVM uses the class object to create a concrete instance object (such as the object above).

For example, in the following Java statement, there will be two objects created:

Employee EMP = new Employee ();

One is the instance object EMP, and the other is the class object, which we can refer to by Employee.class, which has all the static variables and static methods defined by this class, and if we access static content through an EMP object, Will find that it actually points to the object is Employee.class.

This also opens up another mystery: why static content changes in one object (either EMP or EMP2) and also changes in another object, because both objects change the contents of the Employee.class same object.

Now, here's the first argument we're going to cancel. Because static content is actually proven to belong to an object.

But we also need to confirm the second argument: As mentioned earlier, primitive types are not objects in Java and they cannot do similar things. In order to solve this problem, Java official introduced the corresponding wrapper class for each primitive type (for example: Integer corresponding to int,long corresponding Long,character char), so, in fact, now we can create a wrapper object for the original type, They are also related to the operation of objects. And, because of the automatic disassembly box, we can assign a value of the original type to its corresponding wrapper class reference. But we still can't do objects to these primitive types--we need to create the object that corresponds to the wrapper class.

For example:

Integer obj = new integer (5); Here we can do i.tostring (); int i = 5; But we can ' t do i.tostring () here

So far, from an end-user perspective, we can confirm that the original category is not an object. (Java developers are end users of Java because we are using it instead of creating it.)

If you stand in the JVM's perspective, there are new discoveries:

In fact, it seems to the JVM that it treats all "primitive types" as objects, to prove that this can be done through the class source code or the class description in Javadoc.

According to the source code of the Java.lang.Class class, the comments for this class are:

Java Official Description:

Instances of the class class represent classes and interfaces in a running Java application. An enum was a kind of class and an annotation is a kind of interface. Every array also belongs to a class that's reflected as a class object that's shared by all arrays with the same element Type and number of dimensions. The Primitive Java types (Boolean, Byte, char, short, int, long, float, and double), and the keyword void is also Represe nted as Class objects.

Reference:

Instances of class classes represent classes and interfaces for running Java applications. A class and annotation is an interface, like an enumeration. Each array also belongs to a class that is reflected as an object that is shared by all arrays that have the same element type and number of dimensions. The original Java type (Boolean, Byte, char, short, int, long, float, and double) and the keyword Void are also represented as class objects.

At the same time, according to the definition of class.isprimitive () method in Javadoc, we can judge

Java Official Description:

public boolean isprimitive ()
Determines if the specified Class object represents a primitive type.
There is nine predefined Class objects to represent the eight primitive types and void. These is created by the Java Virtual machine, and has the same names as t he primitive types that they represent, namely Boolean,byte, char, short, int, long, float, and double.
These objects may is accessed via the following public static final variables, and is the only Class objects for WHI Ch This method returns True.
Returns:
True if and only if the This class represents a primitive type
Since:
JDK1.1

Reference translation:

public boolean isprimitive ()
Determines whether the specified class object represents a base type.
There are 9 well-defined class objects that represent the corresponding base type and void keyword. These objects are created by the JVM. ...
Return

When and only if the class represents a true base type

All of this shows that inside the JVM, the primitive type is the object.

When you open the Javadoc definition of class, "ctrl+f" finds the keyword "primitive", it will find evidence on the surface "in the JVM, it treats the base type as an object".

We can look at one more example: Integer.type, which is clearly documented in this part of the document:

Java Official Description:

public static final Class<integer> TYPE
The Class instance representing the primitive type int.

All of this shows that inside the JVM, the primitive type is the object.

So, since the "JVM" creates an object for all the basic types, why do we still use "primitive type" instead of using the corresponding wrapper class object directly?

This is because the objects created for the "primitive type" are lightweight inside the JVM, with a lot of optimizations relative to the corresponding wrapper class objects that we create directly, and because of the lightweight, these primitive classes have less functionality (for example, we can't invoke their internal methods because they have been optimized internally without methods)

Use the actual example to illustrate why we should use "primitive type" more:

The "primitive type" has a faster speed (for example, the following code executes, it takes 9 seconds on our machine, but when I change long to long, I finish it in 0 seconds)

public static void Main (string[] args) {    long Millis = System.currenttimemillis ();    Long sum = 0L; Uses long, not a long for    (long i = 0; I <= integer.max_value; i++) {        sum + = i;    }    SYSTEM.OUT.PRINTLN (sum);    System.out.println ((System.currenttimemillis ()-Millis)/1000);}

"Primitive Type" allows us to compare directly with "= ="

New Integer (3) = = new Integer (3); Falsenew integer = = new Integer (100); Falseinteger.valueof (5) = = Integer.valueof (5); Trueinteger.valueof (+) = = integer.valueof (200); False

Let's take a look at the fourth sentence, and the output is really "false". This is because 265 integers in [-128; 127] This interval are stored by the JVM cache, so in this interval the JVM returns the same object, but beyond this interval, the JVM will no longer have caches and new objects are created, so the result is unequal.

So to summarize: inside the JVM, the primitive type is treated as an object. But we developers use the "primitive type" directly as an object, and the developer should use the corresponding wrapper.

That's why I said, "Java is really a purely object-oriented language" of the confirmation process. If you have any other opinions about this, please comment in the comments and discuss together.

Link: http://www.codeceo.com/article/why-java-purely-object-oriented-language.html
English Original: Why Java is a purely object-oriented Language ... Or Why not
Translation Code Rural Network –dee1024
[ reproduced in the text must be marked and retained in the original link, translation links and translators and other information. ]

Is Java really a purely object-oriented language?