# Are primitive types necessary for Game Programming?

This topic is 1786 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I was stumbling around the net and discovered that suggestions have been made for primitive types to be removed from future versions of the Java programming language.  This got me thinking, even though Java more or less "does it for you" when it comes to memory management surely there is an inherent understanding that using primitives instead of objects where appropriate would be better? or is that a false assumption on my part?

For simple things like keeping track of a player's numerical attributes number of lives, health, experience, etc I would have thought using primitive types instead of Object types would have made more sense.

There are other programming languages that don't have primitive types at all, but to my knowledge they aren't as popular for games as C/C++ and Java etc wihich do have primitives.  So the question is quite simply, are primitive types necessary for Game Programming?  Would there be any knock on effects of removing them from a language?

##### Share on other sites
I think you need to define your terms or at least provide a link to these discussions. In most cases "primitive types" mean that the types that are built into the language. If your language doesn't have any primitive types then you can't have any types because there are no types to define them in terms of. How can you have a score if your language doesn't support the idea of numbers? (OK the lambda calculus can give you an example, but there is still a basic primitive data structure used to define integral types.)

##### Share on other sites

I think they must mean, and not sure because it's been a while since I touched Java, but getting rid of the versions of primitive types that don't behave like objects, Like in Java, isn't there int and Integer? and of those only Integer would let you do introspection and could be inserted into the old-style Java containers in which the data values had to inherit from Object and so forth. With Integer in theory you could do some like 2.ToString()...

##### Share on other sites

To clarify, in terms of Java this will mean direct access to primitive types for the purpose of declaring variables will be removed.  Without direct access to these types every variable you declare will be an Object.  So int for example will no longer be available instead you will have to use the Integer class and create an Object.  The language will still have an internal concept of numbers and the ability to manipulate them obviously but in terms of writing code everything will have to be an Object.

Source: The Register: Java won't curl up and die like Cobol, insists Oracle

For the Java Development Kit (JDK) 10 or after, a fundamental change is being discussed: making the Java language Object Oriented. This might see the introduction of a unified type system that turns everything into objects and means no more primitives. The JDK is the developer kit that
is officially released by Oracle, based on the work of the Oracle- and IBM-led OpenJDK project

For example:

public static void main(String[] args)
{
int appleCount = 10;

System.out.println("You have " + appleCount + " apples");
}


This will no longer be possible, instead you will have to use Objects:

public static void main(String[] args)
{
Integer appleCount = new Integer(10);

System.out.println("You have " + appleCount.toString() + " apples");
}


I know this example is unrealistic it's just meant to illustrate the point.

##### Share on other sites

I think they must mean, and not sure because it's been a while since I touched Java, but getting rid of the versions of primitive types that don't behave like objects, Like in Java, isn't there int and Integer? and of those only Integer would let you do introspection and could be inserted into the old-style Java containers in which the data values had to inherit from Object and so forth. With Integer in theory you could do some like 2.ToString()...

IIRC, this is basically part of it.
the idea would basically putting a layer of gloss over int vs Integer, making it look more like 'int' was simply an instance of Integer, ...

practically though, you can't really (actually) get rid of primitive types and have any semblance of performance.

I could be wrong though, given I am not really a Java developer...

##### Share on other sites

I haven't used much Java either, but in C# for example string (lowercase) is an alias for the System.String class, so it's probably the same with your Java example. But as it's also a keyword, in this context it is treated like a primitive type. Conventionally, you use the uppercase String when using its methods and operations.

##### Share on other sites

I haven't used much Java either, but in C# for example string (lowercase) is an alias for the System.String class, so it's probably the same with your Java example. But as it's also a keyword, in this context it is treated like a primitive type. Conventionally, you use the uppercase String when using its methods and operations.

pretty much:
int -> System.Int32
string -> System.String
...

it also allows fairly easily converting between int and object.

int i;
object o;
o=(object)i;
i=(int)o;

it is also very unlikely that Oracle would make a language change which would break pretty much all existing code.

FWIW: my scripting language also does some similar type aliasing, but actually more so, as it is 3 way: variant <-> primitive <-> class.

for example, there is a primitive type (int), a class (Integer), and a variant (fixnum).
so, for example:
var v=3; //type is variant (fixnum)
int i=v; //type is primitive (int)
s=v.toString(); //may quietly send it off to the class (*1)
s=i.toString(); //likewise (*1)

*1: partly pretend here, as implemented, ".toString()" is actually an intrinsic operator in this case, but for some other types it may actually call the "toString()" method...

side note: a fixnum is basically a tagged reference (similar to a pointer), where a few tag bits may indicate whether the reference points to an object, or holds a value such as an integer or floating-point number. this is partly because creating object instances just to convert a primitive to a reference would be unreasonably expensive, and it is much cheaper simply to shove the integer into the reference (in the JIT, for example, converting an 'int' to a 'fixnum' is essentially 2 CPU instructions, namely CDQ+XOR, or would be MOVSX+XOR for x86-64).

however, I make no claim that the language "gets rid of" primitive types, rather than the line between primitive/variant/instance being sometimes slightly fuzzy...

actually, 'string' is another example: in my case it is actually an intrinsic type (as variant) as well, but converts to a 'String' class in the off-chance this is needed. this is partly because there are much cheaper ways to store strings than as object instances (IOW: M-UTF-8 globs of bytes off in a string table somewhere). synthesis-on-demand seemed to be a generally cheaper option than having every in-language string pay the overhead of both a heap-allocated object instance and also a heap-allocated character-array.

...

Java is essentially approaching things from the opposite direction, IIRC with the more recent JVM versions internally adding a fixnum type mostly to fake the presence of an Integer instance, ... (mostly in their effort to make JRuby and Jython perform better). Edited by cr88192

##### Share on other sites

I guess my main gripe with the idea of "Objects Everywhere" is that it will add complexity where it isn't needed.

If I have a player class with an int and an accessor method to get that int I would simply return that int and the value could be used.

With Objects everywhere since objects are passed by reference it wouldn't be possible to pass by value anymore - all primitives in java were passed by value - so now if you want to make sure the caller can't modify your member you'll have to create a copy and pass back the copy instead.

Same goes for calling methods, there'll be a lot more instances where the member will now have to be copied so that it can be passed to a method without worry that it might change the original.

##### Share on other sites

I was stumbling around the net and discovered that suggestions have been made for primitive types to be removed from future versions of the Java programming language.

This is insanity in the Java community.

.Net (C#) has a best-of-both-worlds solution called "boxing".

If they made a change to Java they should implement a similar feature.

Removing primatives would wreck performance. You would have to allocate from the free-store for every field.

It would no longer be possible to create an actual array. You'd always get an array of handles.

##### Share on other sites

I would wager that the argument is that the compiler is sufficiently intelligent to ellide such types' object-ness where possible, or otherwise reduce its space and performance overhead. Certain kinds of features (which Java may or may not have, I'm not familiar) like exporting a type through a library or DLL, JITting, might dissallow or defer the decision, but such is unavoidable. The primitive types naturally side-step such issues by declaring their intent. One approach might be declare an Integer in a special way that restricts the interface -- it might have some benefit to homogeneity of code, but its mostly just turning the problem on its head.

In general, though, if you can achieve similar performance and space utilization, whilst eliminating decisions (or regularizing them), then its best to let the compiler do what it thinks is right.

##### Share on other sites

public static void main(String[] args)
{
int appleCount = 10;

System.out.println("You have " + appleCount + " apples");
}

Why would this syntax need to change? You could also have String number = 10.toString();. I'm sure that you realize there is already not a one to one mapping from syntax to code. The for ( String s : strings) is clearly one example of this. So the above example could be swizzled to "Integer.toString(10);" by the compiler.So I don't see why you'd have to change the syntax to support treating primitives as objects in the language but have them as primitives in the run time. Smalltalk does this.. they are called immediate directs.

##### Share on other sites

I don't think any syntax would need to change ... I think this whole thing is more about adding functionality rather than taking functionality out of Java. In other words, make a list of everything you can do with an Integer that you can't do with an int. Now extend the implementation of the VM or Java libraries or whatever such that you can do all those things with an int. I'd be surprised if this is not what is under discussion.

##### Share on other sites

I think they must mean, and not sure because it's been a while since I touched Java, but getting rid of the versions of primitive types that don't behave like objects, Like in Java, isn't there int and Integer? and of those only Integer would let you do introspection and could be inserted into the old-style Java containers in which the data values had to inherit from Object and so forth. With Integer in theory you could do some like 2.ToString()...

IIRC, this is basically part of it.
the idea would basically putting a layer of gloss over int vs Integer, making it look more like 'int' was simply an instance of Integer, ...

practically though, you can't really (actually) get rid of primitive types and have any semblance of performance.

I could be wrong though, given I am not really a Java developer...

You can remove primitive types from a high level language without losing performance as long as the compiler is good enough to cut away the overhead when its not needed.
This is an advantage all high level languages have, they are usually free to do almost whatever they want with your code as long as the result doesn't change. (Actually writing a compiler that can perform great optmizations is the hard part (and we're still not at the point where compilers always do a better job than a skilled programmer)) Edited by SimonForsman

##### Share on other sites

I'm in the "Java lunacy" bracket here too.

Now, for certain types of code this may be an eminently sensible suggestion.  For people learning about OO, having everything be an object means that everything behaves consistently and there are no weird edge cases.  That's all good stuff.

However it's a clear case of taking something that's good in certain special cases and trying to apply it as good in every general case.  And that's nuts.  With specific reference to game programming, for example, this may be just fine for game logic or scene tree walking, but show me how you'd fill in the pointer returned by a glMapBufferRange call without primitive types and without having to do some awful contortions.

##### Share on other sites

I think they must mean, and not sure because it's been a while since I touched Java, but getting rid of the versions of primitive types that don't behave like objects, Like in Java, isn't there int and Integer? and of those only Integer would let you do introspection and could be inserted into the old-style Java containers in which the data values had to inherit from Object and so forth. With Integer in theory you could do some like 2.ToString()...

IIRC, this is basically part of it.
the idea would basically putting a layer of gloss over int vs Integer, making it look more like 'int' was simply an instance of Integer, ...

practically though, you can't really (actually) get rid of primitive types and have any semblance of performance.

I could be wrong though, given I am not really a Java developer...

You can remove primitive types from a high level language without losing performance as long as the compiler is good enough to cut away the overhead when its not needed.
This is an advantage all high level languages have, they are usually free to do almost whatever they want with your code as long as the result doesn't change. (Actually writing a compiler that can perform great optmizations is the hard part (and we're still not at the point where compilers always do a better job than a skilled programmer))

that is why I wrote "(actually)", as-in, even if at the high-level it all looks like objects, at the CPU level if one is doing much beyond normal integer arithmetic, performance will suffer pretty hard.

so, for most high-level features which exist in a language, there needs to be a way to largely optimize them away in the implementation.

it is sort of like with dynamically-typed languages. the high-level language may look dynamically-typed, but for a reasonably high-performance implementation, the VM will have to aggressively try to eliminate these dynamic types (via type-inference or similar), ...

likewise goes for the JVM faking the existence of instances of the Integer class...

##### Share on other sites

Looks to me like they want to steal some idea from Ruby this time, but only maybe possibly and only 3 versions from now and only if thats really what they want to do. Other than that the linked article doesnt give any real information besides "we continue to work on Java".

Edit: Oh I forgot, they admit Java is the new COBOL.

Edited by wintertime

##### Share on other sites

I was stumbling around the net and discovered that suggestions have been made for primitive types to be removed from future versions of the Java programming language.

This is insanity in the Java community.

.Net (C#) has a best-of-both-worlds solution called "boxing".

If they made a change to Java they should implement a similar feature.

Removing primatives would wreck performance. You would have to allocate from the free-store for every field.

It would no longer be possible to create an actual array. You'd always get an array of handles.

Java already provides this feature it was introduced a while back it's called auto-boxing and unboxing which automatically wraps and unwraps int to Integer and vice versa whenever a primitive is passed when an Object is expected or when an Object is passed when a primitive is expected.

public static void main(String[] args)
{
int appleCount = 10;

System.out.println("You have " + appleCount + " apples");
}

Why would this syntax need to change? You could also have String number = 10.toString();. I'm sure that you realize there is already not a one to one mapping from syntax to code. The for ( String s : strings) is clearly one example of this. So the above example could be swizzled to "Integer.toString(10);" by the compiler.So I don't see why you'd have to change the syntax to support treating primitives as objects in the language but have them as primitives in the run time. Smalltalk does this.. they are called immediate directs.

As said in reply to Shannon, Java already provides this feature, removing primitive types makes this feature redundant so it would likely be removed along with the primitives.

I can't justify removing primitives from Java so I am not going to defend the idea, I posted this thread because I was looking for an explanation as to why this would be suggested and what ramifications there would be as a result.  I was curious to know if it seemed counter intuitive to anyone else so I asked if primitives were needed by programmers.  i personally use primitives where they make sense, i.e. where I don't need an Object but the suggestion that appears to be made is that people want Java to become a language where everything really is an Object.

##### Share on other sites

While boxing/unboxing and all sort of interoperations between int and Integer, or between Java types and native code types (IntBuffer, FloatBuffer, etc) are covered, they have their quirks here and there (specially dealing with collections, sometimes you have to be aware of when the boxing/unboxing is happening), and they still work pretty fine nevertheless.

Thing is, like String, Integer, Float, etc are immutable objects. So one of the worst offenders (performance wise) you could make, which is appending massive quantity of String objects (instead of mutable StringBuilders), could start happening with Integers. Every time you operate on an integer (addition, subtraction, everything) you'd be creating massive amount of new objects.

Probably  JVM devs have some way to deal with that stuff with good performance anyway, the thing is that like String, it will probably end in the list of "Things to watch out for" that a programmer has to have in mind.

"Why my array averaging method is so slow!?"

"Well, you're using an Integer instead of IntegerBuilder. Use an IntegerBuilder and refactor those 30 methods that indirectly depend on Integer's immutability so it doesn't crash everything"

Edited by TheChubu