|
Replies:
8
-
Last Post:
Oct 28, 2004 10:49 AM
by: rreyelts
|
|
|
|
|
|
|
Allow generic primitive types
Posted:
Oct 26, 2004 11:13 AM
|
|
|
This is simple to understand, but probably hard to implement. Allow passing of primitive types to generic declarations. There are many useful places for this, one example is anyware where seperate methods have to be created for each number primitive type.
For example, java.util.Arrays would drop most of its weight. Collections API would not need autoboxing. Imagine the simplifcation of java.awt.geom or java.lang.Math.
|
|
|
|
|
|
|
Re: Allow generic primitive types
Posted:
Oct 26, 2004 11:45 AM
in response to: vikstar
|
|
|
But as autoboxing exists, what would this be useful for?
Monika.
|
|
|
|
|
|
|
|
|
Re: Allow generic primitive types
Posted:
Oct 26, 2004 12:07 PM
in response to: monika_krug
|
|
|
Further, this is about making primitives first class objects in the first place, generics have nothing to do with this.
And although I'd be glad if primitives behave like objects, this is just not feasible, I think
|
|
|
|
|
|
|
|
|
Re: Allow generic primitive types
Posted:
Oct 26, 2004 8:48 PM
in response to: patrikbeno
|
|
|
They would not be first class objects. However, I see the problem with deciding if a generic T should be treated as an object or primitive. So, add a final static field TYPE to the java.lang.Number class standing for any primitive which can be operated on with % * / + - (possibly >> << >>> & | ^ ~ to work on the primitives such as double and float in low level bit representation). So in java.lang.Math such things aspublic static double abs(double a);
public static float abs(float a);
public static int abs(int a);
public static long abs(long a);
all turn into onepublic static <T extends Number.TYPE> T abs(T a);
In the Collections framework we also want to be able to include chars, so only primitive numbers and Object will be to restrictive. Since the Collections framework does not know if it is being passed an Object type or a primitive type it may call such things as toString() or hashCode() on the object, which won't work if a primitive is passed in.
However, instead of making primitive types into first class objects, i suggest only treating them as first class objects. That is, allow additions to the language so that such things as 15.hashCode() or 4.55f.clone() work. All methods in Object could be implemented for primitive types in this way except for the notify and wait methods. Any suggestions on how the notify and wait methods could be implemented for primitive types?
|
|
|
|
|
|
|
|
|
Re: Allow generic primitive types
Posted:
Oct 27, 2004 8:37 AM
in response to: monika_krug
|
|
|
Simply, for performance reasons.
I read of a benchmark of various virtual machines (VMs), both java and .net. Java VMs did perform very well, except that .net VMs proved superior when dealing with collections of primitive types, because .net implementation allows for special treatment of primitive types by the collection framework.
Carlo.
|
|
|
|
|
|
|
|
|
Re: Allow generic primitive types
Posted:
Oct 27, 2004 10:13 AM
in response to: ygmarchi
|
|
|
Can someone please provide a link to these performance benchmarks? I'm curious what the actual performance difference is between the two for primitives.
|
|
|
|
|
|
|
|
|
Re: Allow generic primitive types
Posted:
Oct 28, 2004 10:47 AM
in response to: cowwoc
|
|
|
I'm sure it's not a big deal when you're talking about lists with just hundreds of items, but, I write applications that maintain data structures with millions of objects in them. You can't use Java generics for these data structures, because the cost is far, far too high.
As a very simple example, take a list of 1 million ints. ArrayList<Integer> would require roughly 16M, whereas int[] requires only 4M. Not only do you pay a hefty memory penalty, (which has serious ramifications when it causes cache lines to be replaced 4x as often), but you also pay a speed penalty for boxing every time you write an element and unboxing every time you read one. Even worse, your garbage collection times start to soar, because the garbage collector now has to scan an extra million live Java objects on each collection, whereas, for an int[], it only has 1 single object to scan.
It's just plain stupid. You CAN NOT use the builtin Java libraries for anything of significant size. Creating your own data structures is an absolute pain in the ass, because you have to duplicate them for each and every data type. That's why libraries like fastutil (http://fastutil.dsi.unimi.it) use a preprocessor to generate the different instantiations.
God bless,
-Toby Reyelts
Message was edited by: rreyelts
|
|
|
|
|
|
|
|
|
Re: Allow generic primitive types
Posted:
Oct 27, 2004 10:11 AM
in response to: vikstar
|
|
|
I am sure that people at Sun thought of this when implementing generic types. It would be impossible without making primitives actual objects in the Java language, which would require a huge, incompatible change to the VM and to the Java language.
|
|
|
|
|
|
|
|
|
Re: Allow generic primitive types
Posted:
Oct 28, 2004 1:31 AM
in response to: keithkml
|
|
|
It was certainly considered. I made a proposal that would allow primitives as type arguments during the first public review. The biggest problem wasn't technical, but rather the political problem of reopening the debate about whether primitives should exist at all (i.e. continue to have special status relative to regular objects). The politics of generics have been difficult enough without getting sucked into the debate about primitives/objects.
The basic idea is that to (relatively) easily allow primitives, the type argument has to be constrained so that it can only be replaced by some primitive type. It is when a type argument can be replaced by either a primitive or an object that life gets really difficult.
|
|
|
|
|
java.net RSS
