I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Would Java Be Better Off Without Primitives?

  • submit to reddit

Gilad Bracha raises a fantastic point in his latest blog entry, that Java would be efficient as it is now without having primitives. In fact, Gilad says that Java's original sin is that it's not a proper object oriented language.

As one example, consider type char. When Java was introduced, the Unicode standard required 16 bits. This later changed, as 16 bits were inadequate to describe the world’s characters.

In the meantime, Java had committed to a 16 bit character type. Now, if characters were objects, their representation would be encapsulated, and nobody would very much affected how many bits are needed. A primitive type like char, however, advertises its representation to the world. Consequently, people dealing with unicode in Java have to deal with encoding code points themselves.

The blog entry proves that, even when considering potential performance issues with arrays, there wouldn't have been a significant performance hit to Java had it been fully object oriented. 

While this is something that Gilad has discussed at length, it's something that I had never thought about before. I just accepted primitives as part of the language.  One commenter suggested that using a source keyword in Java 7 and being able to have this change available - although that does seem unlikely.

I also discussed this with Kirk Knoernschild, who isn't a fan of primitives either. 

We had a method that updated a db2 database and essentially encapsulated a SQL statement. The arguments passed into the method were the values inserted/updated/deleted. Because the method took primitives, there was no way to pass in null. So even for columns that were nullable on the database, developers were inserting zero. And there is a big difference between zero and null. The two cannot be treated the same in many cases.


Is this something that others in the community consider to be an issue? 



Arek Stryjski replied on Wed, 2009/05/27 - 4:53am

This is probably the reson why none of the new JDK languages (Groovy, Scala etc.) has primitives. I don't belive it can be fixed in Java itself as it will probably break backward compatibility.

Aljoscha Rittner replied on Wed, 2009/05/27 - 7:35am

Only a brainstorming (with Number):

Define double like:

const Double d = 12.0;

and this is equal to

double d = 12.0;

Now it's possible to write:

String myMessage = "The Number "
+ (d.isInfinite() ? " is " : " is not ")
+ " infinite";

Change the javac compiler and allow a new key word const. Allow the VM to choose the best way to work with const values (as primitives or as objects).

Deprecate all the MAX_VALUE/MIN_VALUE Constants and add new Methods to Class Number:

Number getMaxValue();
Number getMinValue();

IMHO this could be a way without loosing source code compatibility. 

best regards,

Peter Veentjer replied on Wed, 2009/05/27 - 9:06am

It would certainly make instrumentation a lot  easier. Not having to deal with all the different loads/returns etc.

Carlo V. Pasaol II replied on Thu, 2009/05/28 - 12:52am

Definitely an issue... I have encountered "No such method" errors when passing wrappers (Double, Integer, etc.) to methods whose signatures accept primitives (double, int, etc.), usually while using RMI.

martin replied on Thu, 2009/05/28 - 1:51am

Think of java2d for a moment: can You imagine every Point would have x, y of type Double? Or AffineTransform.transform(double[] xy) having some 'more OO oriented' parameter? Without primitive types we would have:

1. 3x bigger memory consumption

2. heavily degraded cpu performance

While it is feasible to calculate 2+1 without creating some temporary objects, any mathematical methods will suffer. It means slow graphics, slow ray tracing, slow audio, slow linear programming, slow simplex method.

And now, what about IO?  We can not simply replace InputStream.read(byte[]) and OutputStream.write(byte[]) to have argument Byte[] (changing data means changing item in array, use 16x more memory). A wrapper (Buffer?) would help here - however it would just throw the dirty work to some c++ code (not so nice, but performant and hidden from our eyes).

Carlo V. Pasaol II replied on Thu, 2009/05/28 - 4:00am in response to: martin

True... But why use an interpreted language for computationally complex programs in the first place?

Walter Bogaardt replied on Thu, 2009/05/28 - 4:35am

16 bits all I need for english. Chinese just will be out of luck, I guess.

James Jamesson replied on Thu, 2009/05/28 - 7:42am in response to: Carlo V. Pasaol II

yeah! how about using an object oriented language with no primitives instead of Java?

Mike P(Okidoky) replied on Fri, 2009/05/29 - 5:34pm in response to: Carlo V. Pasaol II

Java is not interpreted and often runs faster than optimized C++. Only newbies make that mistake. No offense intended at all though.

Mike P(Okidoky) replied on Fri, 2009/05/29 - 5:35pm

Degrading Java to the absolutely astronomically horrible performance of such languages as Groovy...? Thanks but no thanks.

Thierry Milard replied on Fri, 2009/05/29 - 5:43pm

If I was CTO of java-departement at sun I would release, in addition to plain old java,  a "javaNew"  version that would be a good clean up of the langage. java is 12 years old.

- as you say I would kill primitives to make javaNew a simpler language.

- Perhaps I would add cool things javaFx added. 


and voila, everyone would be happy : Enterprises would have their compatibility with plain old java. but for new curious developpers, a "javaNew" language would be simpler to start with.


It is true that COBOL langage did not do this, neither C, not Fortran. We know they lost their momentum. I think doing a new "javaNew" language would prevent java from doing so.

Something sun should think about No ?


Fabrizio Giudici replied on Sun, 2009/05/31 - 9:33am

Excuse the frankness, but it's totally nonsense. :-)

First, when Java was released, there was no way. It was really interpreted at the time and the bad performance would have killed it. This closes the discussion about the "original sin": there was no feasible alternative.

The interesting discussion is about today. In the quoted blog, I don't see any "prove" that there would be the same performance: only the part about arrays has been talked of, but nothing about indexes as for arrays or math, or even number crunching. The most relevant comment above is by "martin" that reminds us that people use Java for a number of things, including 2D, 3D, I/O, I include math (people do image elaboration in Java too). Not to mention that Java ME runs on billions of mobile devices and performance would be still today a big problem for many of them.

This kind of recurring discussion seems to forget that Java success is due to the fact that it is a General Purpose language; in addition, many people fail to understand that "general purpose" means a wider range of things of what they do usually. For more specific domains (that, of course, can be relevant as well) there are other languages and Domain Specific Languages.

As a final point, I don't think why people needing pure objects everywhere just don't forget about "int" and use "Integer". With autoboxing the code is also clean. For instance, whenever I need nullable types (e.g. for the database) I use Integer. Where's the issue?


Raging Infernoz replied on Sun, 2009/05/31 - 11:56pm

This is BS, you need primitives of a known size, for memory efficiency, native code, native mapped buffers, and consistent file IO, including object serialisation e.g. if you changed the size of storage in char, or Character, you would immediately break serialisation of String and Character, including arrays, for file, database, and network IO, including RMI!

Have you actually coded in C on a 16-bit, and a 32-bit, platform, for different OS's?  It was chaos, the datatype definitions were all over the place, the code was not portable, #defines and typdefs did not help; I would really hate to see that happen to Java.

Fabrizio is dead right, if you need objects, use Long, Integer, Short, Byte, Character, and their static factory methods, or autoboxing.

Auto-boxing has shown that the Number Objects can also dangerous, and larger values can be costly for GC, when used correctly, because Sun still hasn't provided mutable versions of all the Number objects, for use in counter or sum Maps; WTF are they waiting for? I've seen private mutable versions of some of these objects, but Sun seem too scared to let people use them!


john green green replied on Mon, 2009/10/26 - 3:26am

Think of java2d for a moment: can You imagine nike shoes russia every Point would have x, y of type Double? Or AffineTransform.transform(double[] xy) having some 'more OO oriented' parameter? Without primitive types we would have:

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.