Level 29

What is autoboxing?

Autoboxing is a mechanism for implicit initialization of objects of wrapper classes (Byte, Short, Character, Integer, Long, Float, Double) with the values ​​of their respective original primitive types (resp. , , , , , , ), bytewithout shortexplicitly charusing intthe longclass floatconstructor double.

Autoboxing occurs when a primitive is directly assigned to a wrapper class (using the " =" operator), or when a primitive is passed to the method parameters (of the "wrapper class" type). Both variables of primitive types and compile-time constants (literals and final-primitives) can be autoboxed into "wrapper classes". In this case, literals must be syntactically correct to initialize a variable of the original primitive type.

Autoboxing variables of primitive types requires an exact match between the type of the original primitive and the type of the "wrapper class". For example, attempting to autobox a variable of type byteto Short, without first explicitly casting it, byte->shortwill cause a compilation error.

The autoboxing of primitive type constants allows for wider matching bounds. In this case, the compiler is able to implicitly expand/narrow the type of primitives beforehand. The transformation takes place in two stages:

1. implicit extension (narrowing) of the original type of the primitive to the type of the primitive corresponding to the wrapper class (to convert int->Byte, first the compiler implicitly narrows intto byte)

2. autoboxing the primitive into the appropriate "wrapper class" (the compiler autoboxes byte->Byte). however, there are two additional restrictions in this case:

• assigning a primitive to a "wrapper" can only be done with the " =" operator (you cannot pass such a primitive to the method parameters without explicit type casting)

• the type of the left operand must not be older than Character, the type of the right operand must not be older than int, (expansion/narrowing byte <-> short, byte <-> char, short <-> char
  and only narrowing byte <- int, short <- int, char <- int, all other options require explicit type casting)

An additional feature of the integer "wrapper classes" generated by autoboxing constants in the range -128 +127 is that they are cached by the JVM. Therefore, such wrappers with the same values ​​will be references to one object.

Why is it used autoboxing?

I will quote the lecture:

As far as you remember, Java has both types inherited from the class Objectand primitive types. But, as it turned out, such a convenient thing as collections and generics can only work with types inherited from Object.

Alternatives autoboxing?

Didn't find an answer, but posted on StackOverFlow .

Based on this discussion, it appears that the alternative autoboxingto `y is to use primitive types, since using autoboxing`a reduces performance. Conclusion: use autoboxingonly where necessary.

Article written about Autoboxing: Autoboxing: Traps and Advantages

Wrapper types for primitive types mutableor immutable?

Immutable, since primitive objects are also immutable. To work as a Mutabletype there is a class MutableInteger, etc.

How are primitive types converted to non-primitive counterparts?

This and the following questions are well answered by this article: Autoboxing and Unpacking in Java

This is the conclusion from it: autoboxing is a mechanism for implicitly converting primitive data types into appropriate wrapper classes (objects). The compiler uses a method valueOf()to convert primitive types to objects, and methods IntValue(), doubleValue()etc. to get primitive types from an object (that is, reverse conversion). Autoboxing converts boolean type booleanto Boolean, byteto Byte, charto Character, floatto Float, intto Integer, longto Long, shortto Short. Unpacking occurs in the opposite direction.

How are non-primitive types cast to primitive?

Answered above.

How are primitive and non-primitive types compared?

This is discussed in detail in the lecture, but I found it, so to speak, the same thing, but in other words.

There are two ways in Java to compare objects for equality, ==and the equals().

==used for primitive types. For " ==" objects, this is purely reference comparison. For other cases, you need to use the equals(). Moreover, the method hashCode()serves (in theory) for the same purpose. It is considered good manners if you override equals()and hashCode(). After initialization of some objects a and b , the following rule must be fulfilled:

If the expression a.equals(b)returns true , then it a.hashCode()must be equal to b.hashCode().

Does the operation always create a new object autoboxing?

It's in the lectures:

When we assign a value of type Integer int, the method is called Integer.valueOf: the function valueOfdoes not always create a new object of type Integer. It caches values ​​from -128 to 127.

If the passed value goes beyond these limits, then a new object is created, and if not, then no.

If we write new Integer(), then a new object is guaranteed to be created. If we call Integer.valueOf(), explicitly or with autoboxing, then this method can return for us both a new object and give an object from the cache if the passed number lies in the range from -128 to 127.

How does on-operation caching work autoboxing?

Answered in the question above, just in case I created a question on StackOverFlow , but they answer the same thing

What types and/or values ​​does caching work for?

In the eighth question. If anyone has any thoughts on the last three questions, then write in the comments.