We Keep Coding

Do Java generics allow for memory savings in arrays of primitives such as short?

I've done a bit of Googling, but I've been unable to find a decisive answer to this question. For clarification, consider a class like this:
public class MyContainer<T> {
private T[] _store;
private int _size;
...
}
Is it possible to achieve the memory savings one would get by using an array of type short vs. int, despite the fact that a variable with a reference to MyContainer must be declared with primitive wrapper classes like Short and Integer, and instances of MyContainer must be created with those same wrapper classes?
In my searches I found that the Java compiler applies type erasure to generics, but I'm not so sure that I can now assume Java does not have some sort of optimization for generically-typed arrays.
Does anyone have evidence for or against this? Thanks in advance.

Generics themselves don't offer any memory saving, and Integer/Short are larger than the primitive equivalent.
Using Integer.valueOf( int) or Short.valueOf( short), or just plain auto-boxing, will however re-use shared instances for common small positive & negative numbers. So that can save memory over instantiating each value separately.
See: http://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#valueOf(int)
Generics are an object reference type, and will thus tend to be somewhat larger/slower than an array of primitive int or short. Java applies no space or time optimizations to a generic collection such as List<Integer> compared to other Lists, since internally the JVM shares the same class & bytecode between all List instances. This is true of arrays also.
Don't worry about memory or performance, unless this is core code to be used near the bottom of a performance-critical stack. Only the deepest-looped, heavily-used & most performance-constrained code sections should be candidates for design-stage optimization.

No. Generics have nothing to do with either primitives or memory saving.

Is it possible to achieve the memory savings one would get by using an array of type short vs. int, despite the fact that a variable with a reference to MyContainer must be declared with primitive wrapper classes like Short and Integer, and instances of MyContainer must be created with those same wrapper classes?
Just to build on the existing answers, it is possible to implement a generic collection interface with a backing primitive array, but not generically. For example Guava's Ints.asList(int...) returns a List<Integer> implementation that's backed by an int[] and simply boxes/unboxes on all its method calls. But Guava has separate implementations of that pattern for each primitive - there's no way to unify it like you're hoping to do.

Another approach is to use
TIntArrayList.wrap(int[] array)
from the Trove4j library which wraps your array into Trove's collection allowing you to save memory and add standard Java's ArrayList features like auto-expanding, sorting, selecting, iterating etc.
And to for compliance with Java collections (List), you use the decorator
new TIntListDecorator(TIntList list)

Java collections. Why no Primitive Types? [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
storing primitive values in a java collection?
My Java textbook says elements of a collection, for example ArrayList, cannot be primitive types. Is there a reason for this? I mean did someone at Sun decide on this or is there some barrier against doing it? I understand my example half-answers my question since ArrayList requires an object and primitives are not objects. But then I think why can't they have primitive types as well?

is there some barrier against doing
it?
You could write near-identical versions of ArrayList that were tailor made to store one of the non-class types, e.g. IntegerArrayList and so on. The barrier against this is that there would be an explosion of such classes, as you'd multiply the number of primitive types by the number of collection types. In order to keep the standard collection framework manageable, this was ruled out.
To solve this more neatly in the language, you'd need generics to allow primitive types to serve as type parameters, and improve the interaction between arrays and generics.

Storing unwrapped primitives would dramatically complicate the collections code. Whereas, with the wrappers (Integer for int, etc.), the code is fairly straight-forward. For several years now, Java has supported "auto-boxing", which means that if you give an int where an Integer is expected, the int is wrapped up in an Integer instance for you (and vice-versa).

There are objects called "wrappers" that represent all of the primitive types. For example, there is a class called Integer that supports int. You can use the primitive wrappers to hold values in a Collection.
The problem with primitive types (at least until Java 5) is that they didn't extend from the base Object class. All of the collections need to specify a class for all the methods they are using - and they specify Object, since Object is the base of all the classes.
As of Java 5, you will find that Java will implicitly switch between a primitive and it's corresponding wrapper class when you need it. This means you can add an int, or a double, etc. to a Collection. The VM will automatically wrap the primitive in a wrapper class for you and place the wrapper in the Collection.

Currently the only way to store primtives directly into a collection, is to have a collection for each primitive type e.g. TIntArrayList.
You are likely to find that even though ArrayList is slower than using primitives, it is fast enough for 90+% of use cases.

Read this article on wikipedia. It might help: http://en.wikipedia.org/wiki/Object_type_(object-oriented_programming)#Autoboxing
In computer science, an object type
(a.k.a. wrapping object) is a datatype
which is used in object-oriented
programming to wrap a non-object type
to make it look like a dynamic object.
Some object-oriented programming
languages make a distinction between
reference and value types, often
referred to as objects and non-objects
on platforms where complex value types
don't exist, for reasons such as
runtime efficiency and syntax or
semantic issues. For example, Java has
primitive wrapper classes
corresponding to each primitive type:
Integer and int, Character and char,
Float and float, etc. Languages like
C++ have little or no notion of
reference type; thus, the use of
object type is of little interest.
Boxing is the process of placing a
primitive type within an object so
that the primitive can be used as a
reference object. For example, lists
may have certain methods which arrays
might not, but the list might also
require that all of its members be
dynamic objects. In this case, the
added functionality of the list might
be unavailable to a simple array of
numbers. For a more concrete example,
in Java, a LinkedList can change its
size, but an array must have a fixed
size. One might desire to have a
LinkedList of ints, but the LinkedList
class only lists references to dynamic
objects — it cannot list primitive
types, which are value types.
To circumvent this, ints can be boxed
into Integers, which are dynamic
objects, and then added to a
LinkedList of Integers. (Using generic
parameterized types introduced in J2SE
5.0, this type is represented as LinkedList.) On the other
hand, C# has no primitive wrapper
classes, but allows boxing of any
value type, returning a generic Object
reference.
The boxed object is always a copy of
the value object, and is usually
immutable. Unboxing the object also
returns a copy of the stored value.
Note that repeated boxing and unboxing
of objects can have a severe
performance impact, since it
dynamically allocates new objects and
then makes them eligible for Garbage
collection.

Performance issue is one of the problems since we need auto-boxing for this to be achieved. Also some of the structures may benefit from having null values also.

Why are there wrapper classes in Java? [duplicate]

This question already has answers here:
Java: Why are wrapper classes needed?
(12 answers)
Closed 6 years ago.
I know what a wrapper class is, they wrap primitive types (e.g. int, double, etc) to objects of their respective class.
But, why do we need Wrapper classes in the first place? Why not simply go with primitive types where we have them?

Several possible reasons:
So that a null value is possible
To include in a Collection
To treat generically / polymorphically as an Object along with other Objects

Am example of when wrappers are used would be in Collections, you can have an ArrayList<Integer>, but not an ArrayList<int> same with HashMaps etc. To get type safety we use generics and generics need objects not primitives.

Java is an object oriented programming language. I think you could also ask - why do we have primitives and why is everything not just an object?
Java designers kept the two separate to keep things simple. You use the wrappers when you need types that fit in the object oriented world - like polymorphism, collections etc. You use the primitives when you need efficiency.

Wrapper classes are used instead of primitive types when an Object is expected.
In Collections for example, an ArrayList may contain instances of any subclass of Object, but because primitive types are not Objects, they could not be contained in the ArrayList.

Wrapper classes are used to convert any primitive type into an object.The primitive data types are not objects, they do not belong to any class, they are defined in the language itself. While storing in data structures which support only objects, it is required to convert the primitive type to object first, so we go for wrapper class.

Wrapper Class:
Java uses primitive types, such as int, char, double to hold the
basic data types supported by the language.
Sometimes it is required to create an object representation of these
primitive types.
These are collection classes that deal only with such objects. One
needs to wrap the primitive type in a class.
To satisfy this need, java provides classes that correspond to each of the primitive types. Basically, these classes encapsulate, or wrap, the primitive types within a class.
Thus, they are commonly referred to as type wrapper. Type wrapper
are classes that encapsulate a primitive type within an object.
The wrapper types are Byte, Short, Integer, Long, Character,
Boolean, Double, Float.

Java is an object-oriented language and as said everything in java is
an object. But what about the primitives? They are sort of left out in
the world of objects, that is, they cannot participate in the object
activities, such as being returned from a method as an object, and
being added to a Collection of objects, etc. . As a solution to this
problem, Java allows you to include the primitives in the family of
objects by using what are called wrapper classes.

There are three reasons that you might use a Number object rather than a primitive:
As an argument of a method that expects an object (often used when
manipulating collections of numbers).
To use constants defined by the class, such as MIN_VALUE and
MAX_VALUE, that provide the upper and lower bounds of the data type.
To use class methods for converting values to and from other
primitive types, for converting to and from strings, and for
converting between number systems (decimal, octal, hexadecimal,
binary).
Source from:
The Numbers Classes

One pragmatic reason off the top of my head is that Objects can be null, primitives cannot*. If I can't ensure that a function can return an int, using the wrapper is the only way to deal with getting the int I expect. Autoboxing takes care of the rest.

Java: Why are wrapper classes needed?

On the very high level, I know that we need to "wrap" the primitive data types, such as int and char, by using their respective wrapper classes to use them within Java collections.I would like to understand how Java collections work at the low level by asking:"why do we need to wrap primitive data types as objects to be able to use them in collections?"I thank you in advance for your help.

Because Java collections can only store Object References (so you need to box primitives to store them in collections).
Read this short article on Autoboxing for more info.
If you want the nitty gritty details, it pretty much boils down to the following:
Local Primitives are stored on the Stack. Collections store their values via a reference to an Object's memory location in the Heap. To get that reference for a local primitive, you have to box (take the value on the Stack and wrap it for storage on the Heap) the value.

At the virtual machine level, it's because primitive types are represented very differently in memory compared to reference types like java.lang.Object and its derived types. Primitive int in Java for example is just 4 bytes in memory, whereas an Object takes up at minimum 8 bytes by itself, plus another 4 bytes for referencing it. Such design is a simple reflection of the fact that CPUs can treat primitive types much more efficiently.
So one answer to your question "why wrapper types are needed" is because of performance improvement that it enables.
But for programmers, such distinction adds some undesirable cognitive overhead (e.g., can't use int and float in collections.) In fact, it's quite possible to do a language design by hiding that distinction --- many scripting languages do this, and CLR does that. Starting 1.5, Java does that, too. This is achieved by letting the compiler silently insert necessary conversion between primitive representation and Object representation (which is commonly referred to as boxing/unboxing.)
So another answer to your question is, "no, we don't need it", because the compiler does that automatically for you, and to certain extent you can forget what's going on behind the scene.

Read all of the answers, but none of them really explains it simply in layman terms.
A wrapper class wraps(encloses) around a data type (can be any primitive data type such as int, char, byte, long) and makes it an object.
Here are a few reasons why wrapper classes are needed:
Allows null values.
Can be used in collection such as List, Map, etc.
Can be used in methods which accepts arguments of Object type.
Can be created like Objects using new ClassName() like other objects:
Integer wrapperInt = new Integer("10");
Makes available all the functions that Object class has such as clone(), equals(), hashCode(), toString() etc.
Wrapper classes can be created in two ways:
Using constructor:
Integer i = new Integer("1"); //new object is created
Using valueOf() static method:
Integer i = Integer.valueOf("100"); //100 is stored in variable
It is advised to use the second way of creating wrapper classes as it takes less memory as a new object is not created.

To store the Primitive type values in Collection. We require Wrapper classes.

Primitive data types can't be referenced as memory addresses. That's why we need wrappers which serve as placeholders for primitive values. These values then can be mutated and accessed, reorganized, sorted or randomized.

Collection uses Generics as the bases. The Collection Framework is designed to collect, store and manipulate the data of any class. So it uses generic type. By using Generics it is capable of storing the data of ANY CLASS whose name you specify in its declaration.
Now we have various scenario in which want to store the primitive data in the same manner in which the collection works. We have no way to store primitive data using Collection classes like ArrayList, HashSet etc because Collection classes can store objects only. So for storing primitive types in Collection we are provided with wrapper classes.
Edit:
Another benefit of having wrapper classes is that absence of an object can be treated as "no data". In case of primitive, you will always have a value.
Say we have method signature as
public void foo(String aString, int aNumber)
you can't make aNumber as optional in above method signature.
But if you make signature like:
public void foo(String aString, Integer aNumber)
you have now made aNumber as optional since user can pass null as a value.

See Boxing and unboxing: when does it come up?
It's for C#, but the same concept apply to Java. And John Skeet wrote the answer.

Well, the reason is because Java collections doesn't differentiate between primitive and Object. It processes them all as Object and therefore, it will need a wrapper. You can easily build your own collection class that doesn't need wrapper, but at the end, you will have to build one for each type char, int, float, double, etc multiply by the types of the collections (Set, Map, List, + their implementation).
Can you imagine how boring that is?
And the fact is, the performance it brings by using no wrapper is almost negligible for most applications. Yet if you need very high performance, some libraries for primitive collections are also available (e.g. http://www.joda.org/joda-primitives/)

Wrapper classes provide useful methods related to corresponding data types which you can make use of in certain cases.
One simple example. Consider this,
Integer x=new Integer(10);
//to get the byte value of 10
x.byteValue();
//but you can't do this,
int x=10;
x.byteValue(); //Wrong!
can you get the point?

If a variable is known to either hold a specific bit pattern representing null or else information which can be used to locate a Java Virtual Machine object header, and if the method for reading an object header given a reference will inherently trap if given the bit pattern associated with null, then the JVM can access the object identified by the variable on the assumption that there is one. If a variable could hold something which wasn't a valid reference but wasn't the specific null bit pattern, any code which tried to use that variable would have to first check whether it identified an object. That would greatly slow down the JVM.
If Object derived from Anything, and class objects derived from Object, but primitives inherited from a different class derived from Anything, then in a 64-bit implementation it might be practical to say that about 3/4 of the possible bit patterns would represent double values below 2^512, 1/8 of them to represent long values in the range +/- 1,152,921,504,606,846,975, a few billion to represent any possible value of any other primitve, and the 1/256 to identify objects. Many kinds of operations on things of type Anything would be slower than with type Object, but such operations would not be terribly frequent; most code would end up casting Anything to some more specific type before trying to work with it; the actual type stored in the Anything would need to be checked before the cast, but not after the cast was performed. Absent a distinction between a variable holding a reference to a heap type, however, versus one holding "anything", there would be no way to avoid having the overhead extend considerably further than it otherwise would or should.

Much like the String class, Wrappers provide added functionality and enable the programmer to do a bit more with the process of data storage. So in the same way people use the String class like....
String uglyString = "fUbAr";
String myStr = uglyString.toLower();
so too, they can with the Wrapper. Similar idea.
This is in addition to the typing issue of collections/generics mentioned above by Bharat.

because int does not belongs any class .
we convert datatype(int) to object(Interger)

Why do some languages need Boxing and Unboxing?

This is not a question of what is boxing and unboxing,
it is rather why do languages like Java and C# need that ?
I am greatly familiar wtih C++, STL and Boost.
In C++ I could write something like this very easily,
std::vector<double> dummy;
I have some experience with Java, but I was really surprised because I had to write something like this,
ArrayList<Double> dummy = new ArrayList<Double>();
My question, why should it be an Object, what is so hard technically to include primitive types when talking about Generics ?

what is so hard technically to include primitive types when talking about Generics ?
In Java's case, it's because of the way generics work. In Java, generics are a compile-time trick, that prevents you from putting an Image object into an ArrayList<String>. However, Java's generics are implemented with type erasure: the generic type information is lost during run-time. This was for compatibility reasons, because generics were added fairly late in Java's life. This means that, run-time, an ArrayList<String> is effectively an ArrayList<Object> (or better: just ArrayList that expects and returns Object in all of its methods) that automatically casts to String when you retrieve a value.
But since int doesn't derive from Object, you can't put it in an ArrayList that expects (at runtime) Object and you can't cast an Object to int either. This means that the primitive int must be wrapped into a type that does inherit from Object, like Integer.
C# for example, works differently. Generics in C# are also enforced at runtime and no boxing is required with a List<int>. Boxing in C# only happens when you try to store a value type like int in a reference type variable like object. Since int in C# inherits from Object in C#, writing object obj = 2 is perfectly valid, however the int will be boxed, which is done automatically by the compiler (no Integer reference type is exposed to the user or anything).

Boxing and unboxing are a necessity born out of the way that languages (like C# and Java) implement their memory allocation strategies.
Certain types are allocated on the stack and other on the heap. In order to treat a stack-allocated type as a heap-allocated type, boxing is required to move the stack-allocated type onto the heap. Unboxing is the reverse processes.
In C# stack-allocated types are called value types (e.g. System.Int32 and System.DateTime) and heap-allocated types are called reference types (e.g. System.Stream and System.String).
In some cases it is advantageous to be able to treat a value type like a reference type (reflection is one example) but in most cases, boxing and unboxing are best avoided.

I believe this is also because primitives do not inherit from Object. Suppose you have a method that wants to be able to accept anything at all as the parameter, eg.
class Printer {
public void print(Object o) {
...
}
}
You may need to pass a simple primitive value to that method, like:
printer.print(5);
You would be able to do that without boxing/unboxing, because 5 is a primitive and is not an Object. You could overload the print method for each primitive type to enable such functionality, but it's a pain.

I can only tell you for Java why it doesn't support primitve types in generics.
First there was the problem that the question to support this everytime brought on the discussion if java should even have primitive types. Which of course hindered the discussion of the actual question.
Second the main reason not to include it was that they wanted binary backward compatibility so it would run unmodified on a VM not aware of generics. This backward compatibility/migration compatibility reason is also why now the Collections API supports generics and stayed the same and there isn't (as in C# when they introduced generics) a complete new set of a generic aware Collection API.
The compatibility was done using ersure (generic type parameter info removed at compile time) which is also the reason you get so many unchecked cast warnings in java.
You could still add reified generics but it's not that easy. Just adding the type info add runtime instead of removing it won't work as it breaks source & binary compatibility (you can't continue to use raw types and you can't call existing compiled code because they don't have the corresponding methods).
The other approach is the one C# chose: see above
And automated autoboxing/unboxing wasn't supported for this use case because autoboxing costs too much.
Java theory and practice: Generics gotchas

Every non-array non-string object stored on the heap contains an 8- or 16-byte header (sizes for 32/64-bit systems), followed by the contents of that object's public and private fields. Arrays and strings have the above header, plus some more bytes defining the length of the array and size of each element (and possibly the number of dimensions, length of each extra dimension, etc.), followed by all of the fields of the first element, then all the fields of the second, etc. Given an reference to an object, the system can easily examine the header and determine what type it is.
Reference-type storage locations hold a four- or eight-byte value which uniquely identifies an object stored on the heap. In present implementations, that value is a pointer, but it's easier (and semantically equivalent) to think of it as an "object ID".
Value-type storage locations hold the contents of the value type's fields, but do not have any associated header. If code declares a variable of type Int32, there's no need to need to store information with that Int32 saying what it is. The fact that that location holds an Int32 is effectively stored as part of the program, and so it doesn't have to be stored in the location itself. This an represent a big savings if, e.g., one has a million objects each of which have a field of type Int32. Each of the objects holding the Int32 has a header which identifies the class that can operate it. Since one copy of that class code can operate on any of the million instances, having the fact that the field is an Int32 be part of the code is much more efficient than having the storage for every one of those fields include information about what it is.
Boxing is necessary when a request is made to pass the contents of a value-type storage location to code which doesn't know to expect that particular value type. Code which expects objects of unknown type can accept a reference to an object stored on the heap. Since every object stored on the heap has a header identifying what type of object it is, code can use that header whenever it's necessary to use an object in a way which would require knowing its type.
Note that in .net, it is possible to declare what are called generic classes and methods. Each such declaration automatically generates a family of classes or methods which are identical except fort he type of object upon which they expect to act. If one passes an Int32 to a routine DoSomething<T>(T param), that will automatically generate a version of the routine in which every instance of type T is effectively replaced with Int32. That version of the routine will know that every storage location declared as type T holds an Int32, so just as in the case where a routine was hard-coded to use an Int32 storage location, it will not be necessary to store type information with those locations themselves.

In Java and C# (unlike C++) everything extends Object, so collection classes like ArrayList can hold Object or any of its descendants (basically anything).
For performance reasons, however, primitives in java, or value types in C#, were given a special status. They are not object. You cannot do something like (in Java):
7.toString()
Even though toString is a method on Object. In order to bridge this nod to performance, equivalent objects were created. AutoBoxing removes the boilerplate code of having to put a primitive in its wrapper class and take it out again, making the code more readable.
The difference between value types and objects in C# is more grey. See here about how they are different.