Skip to Main Content

Java APIs

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

a solution to avoid autoboxing

843793Sep 24 2003 — edited Oct 14 2003
Hello gentlemen,

the purpose of this thread is to propose a solution to avoid autoboxing.

The question is to see if it's posible to store a primitive type in a generic Collection
without autoboxing. To do it we can introdiuce a type named Type wich is over
the class Object. Then we have to allow to a primitive type to be a Type.
You just have to see that a primitive type will not be an Object.
But we allow to the primitive type to have the null value when the primitive type is undefine.
This value as the same purpose as the NULL value in a relationnal database.

A Type has the following methods :

protected Type clone()
protected Type compareTo()(Type t)
public boolean equals(Type t)
public TypeDescriptor getType()
public int hashCode()
public boolean isPrimitive()
public String toString()

A PrimitiveType herited from a Type.
A boolean, an int, a float, a char ect... are a PrimitiveType.

An Object herited from a Type

For this solution, the primitive types have the possibility to be null. But there are not reference type as the Object class.

The methode public Type compareTo(Type t) is use for primitive types.
this methode is equivalent of the use of the comparator <, == and >.
For an Object the methode compareTo() can simply return
the comparaison beetwen the adresse, if the Object is not comparable.

The methode public boolean isPrimitive() is use for primitive type too. This method return true if it's a primitive type or false if it's an Object.

The methode public TypeDescriptor getType() give the information of the type as the methode public Class getClass() for the Object.

Then, we have to redefine all the collections so that there store a Type instead an Object This solution avoid autoboxing.

This solution :
1) avoid for example the convertion between an int to an
Integer, which cost memory and processing time for the
instanciation of an equivalent Object.
2) allow a better mapping between Relationnal database and Java class.
3) allow a primitive type to be null when it is undifined.
4) allow a gain of memory during the storage of a great number of
primitive type instead of Object in a collection.

But there is a probleme in this solution. This is the choose of the value of the null for the primitive type when there have to be serialiazed or store one a disk.
An another problem is the interoperability with the other langage as C, C++ or other Oriented Object Language.

Let's give now an example of a List. The class List would have these methodes :

Method Summary :
void add(int index, Type element)
boolean add(Type t)
void clear()
boolean contains(Type t)
boolean equals(Type t)
Type get(int index)
int hashCode()
int indexOf(Type t)
boolean isEmpty()
Iterator iterator()
int lastIndexOf(Type t)
Type remove(int index)
boolean remove(Type t)
Type set(int index, Type element)
int size()
Type[] toArray()
Type[] toArray(Type a)

the primitive types could be use with the Type's methods. But there are not Object.
public class TestPrimitiveType{  
  public static void main(String args[]){    
    int i = 1;
    int j = 2;
    
    if( i.compareTo(j)== -1)      
      System.out.println(  i.toString() 
         +  "<" + j.toString()); //toString() can be avoid
    else      
      System.out.println(i.toString() 
           + "<" + j.toString());    
      
    Type t = i;    
    
    if( t.isPrimitive())
      System.out.println( "it's a primitive type!" );     
     
    List aList = new ArrayList();    
    aList.add(t);    
    aList.add(j);    
    System.out.println(aList);  
  }
}
The use of a generic List<Type> would give :
public class TestTypeGeneric{  
  public static void main(String args[]){    
    List<int> anIntList = new ArrayList<int>();    
    
    anIntList.add(1);
    anIntList.add(2);    
    System.out.println(anIntList);  
  }
}
Conclusion :

This thread try to give a solution to avoid autoboxing. I think that this solution simplify
the complexification of the JAVA language.

Thank for your remarks.

Good Bless You.

Artscene.
Comments
Locked Post
New comments cannot be posted to this locked post.
Post Details
Locked on Nov 11 2003
Added on Sep 24 2003
11 comments
430 views