Skip to main content

Allow generic primitive types

8 replies [Last post]
vikstar
Offline
Joined: 2004-04-23
Points: 0

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.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ygmarchi
Offline
Joined: 2003-06-10
Points: 0

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.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Can someone please provide a link to these performance benchmarks? I'm curious what the actual performance difference is between the two for primitives.

rreyelts
Offline
Joined: 2003-06-10
Points: 0

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 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 [b]CAN NOT[/b] 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

keithkml
Offline
Joined: 2003-06-10
Points: 0

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.

mthornton
Offline
Joined: 2003-06-10
Points: 0

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.

monika_krug
Offline
Joined: 2004-10-14
Points: 0

But as autoboxing exists, what would this be useful for?

Monika.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

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

vikstar
Offline
Joined: 2004-04-23
Points: 0

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 as[code]public static double abs(double a);
public static float abs(float a);
public static int abs(int a);
public static long abs(long a);[/code]all turn into one[code]public static T abs(T a);[/code]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?