Generics are cool

[Lee Fesperman]

IMO, autoboxing sucks.

AFAICS, it's only good if your point of comparison is the previous version
of Java.

Take a slightly less myopic perspective - and surely the best thing is
never to have had primitive types in the first place.

I'd view that as a myopic perspective. Java wouldn't be appropriate for certain
high-performance applications if that were true. In that case, my company would not have
built an RDBMS in Java, which would be too bad because we support Java objects in the
database and run their methods natively ... something Oracle, SQL Server, DB2 can't do.
We see that as a big win.

 

[Lasse Reichstein Nielsen]

I'd view that as a myopic perspective. Java wouldn't be appropriate
for certain high-performance applications if that were true.

Sure it would. You don't have to make an inefficient implementation
just because primitive types looks like objects at the language level.

Other languages have had primitive types as objects with efficient
implementations (starting with Smalltalk, and probably including C#).

/L

 

[Bent C Dalager]

Besides which autoboxing should cause no performance problems that


c.add( new Boolean ( false ) );

does not. It's the same thing.

I believe it's more akin to
c.add(Boolean.FALSE);
which should be rather more effecient.

For Integers, I think it has a pool of all ints from 0 to 1000 or
somesuch to optimize commonly used numbers.

Cheers
Bent D

 

[Lee Fesperman]

Sure it would. You don't have to make an inefficient implementation
just because primitive types looks like objects at the language level.

Other languages have had primitive types as objects with efficient
implementations (starting with Smalltalk, and probably including C#).

I know. It just seems pretty hard with dynamic loading, serialization, ... And, I'd be
looking for an absolute guarantee. In Java, I can predict the performance of code almost
as well as C. Even though in C I knew the machine code generated.

I don't think that high performance type applications are common in Smalltalk. Are there
several RDBMSs written in Smalltalk?

 

[Phillip Lord]

Antti> (e-mail address removed) wrote in comp.lang.java.programmer:Joseph> On second thought, perhaps Generics simply provides javac
Joseph> the information it needs to implement autoboxing.
Antti> No. There are only assumptions.

The information that you need for autoboxing is there.

Actually, not quite, as I left the cast out which should have been
there.


Antti> In the second case you do not know what comes out of
Antti> the collection. You only _assume_ it is a boolean,
Antti> since the programmer wants one.


Yes. But we are talking about autoboxing here. There is no requirement
for autoboxing to be type safe.

Collection c;
boolean b;
int i;

c.add( b );
i = (int)c.get();

will crash with a ClassCast. But there again so will this code.


Collection c;
Boolean b;
Integer i;

c.add( b );
i = (Integer)c.get();

In the first case you have all enough information to work out that
autoboxing should be compiled in.

c.add( b );

You are calling a Collection method which takes Object with a
primitive int. Therefore it should be boxed with an Integer.

i = (int)c.get();

You are returning an Object where only a int can be
expected, therefore it should be unboxed with an IntegerValue, or
Integer.valueOf, or however it is compiled.

What generics gives you in addition is the guarantee that the second
call will not crash with ClassCast. But you could have had autoboxing
without generics, and some people will use it that way.

Cheers

Phil

 

[Chris Uppal]

Sure it would. You don't have to make an inefficient implementation
just because primitive types looks like objects at the language level.

I imagine that there are some circumstances where the even the very moderate
slow-down caused by using these implementation techniques would be
unacceptable. Perhaps not many, but certainly some. So one option would have
been to make "normal" numbers be represented as full objects (but not, of
course, allocated from the heap) using the standard "unboxed representation"
(nothing to do with auto-boxing), but also allow programmers to use primitive
types for those rare occasions where the normal representation wasn't fast
enough.

Interestingly, Java's static typing would allow an unboxed representation to be
/more/ efficient than it is in Smalltalk[*], since quite a few runtime tests
(is this "pointer" a real object or is it an unboxed integer) could be
optimised away by the JITer.

([*] Or, more accurately, to allow a given level of performance to be achieved
with less effort put into the VM implementation.)

Other languages have had primitive types as objects with efficient
implementations (starting with Smalltalk, and probably including C#).

I think the first language to use unboxed integers was LISP, though the same
trick has been used in Smalltalk for many years.

-- chris

 

[Chris Uppal]

I'd view that as a myopic perspective. Java wouldn't be appropriate for
certain high-performance applications if that were true. In that case, my
company would not have built an RDBMS in Java, which would be too bad

I /very much/ doubt whether Java with Smalltalk/LISP style integers would be
any less suitable for implementing an RDMS.

Of course, I could be wrong -- perhaps your DB's efficiency is dominated by
numeric calculations (rather than by disk-seeks and other IO), but if so then
I'd say there something Very Wrong with your DB...

-- chris

 

[Chris Uppal]

Joseph> I read that this weekend. Oh, well, yet another Java
Joseph> feature I will not be using. Too bad.


Don't be so hasty. If you write an app which this feature a lot, then
it might cause performance problems. But it is nearly always wrong to
assume that know what will cause performance problems

The problem is not so much that autoboxing /may/ or /does/ cause performance
problems (and IMO the problems are more likely to be in memory consumption and
GC load than execution time), as that the code is actually doing something much
more complicated than it appears. That throws programmers' intuitions off, and
can (and does) lead people into making expensive mistakes, which they may find
difficult to diagnose.

There's nothing wrong (for most purposes) with stuffing a few int-s into a
Collection using auto-boxing. The problem is that that doesn't scale, but it
/looks/ as if it is harmless.

(For a recent example on this ng: the gent who was keeping around 10 million
32-bit int-s in ArrayLists -- and couldn't understand why he was running out of
memory. That thread was quite illuminating, since there were all sorts of
suggestions as to what his problem might be, and it wasn't until the
conversation had gone on for quite some time that the real problem emerged. He
had, of course, no idea that auto-boxing was behind his problems, and so he
didn't mention that he was keeping lots of int-s in ArrayLists.)

-- chris

 

[Phillip Lord]

Chris> There's nothing wrong (for most purposes) with stuffing a few
Chris> int-s into a Collection using auto-boxing. The problem is
Chris> that that doesn't scale, but it /looks/ as if it is harmless.

Chris> (For a recent example on this ng: the gent who was keeping
Chris> around 10 million 32-bit int-s in ArrayLists -- and couldn't
Chris> understand why he was running out of memory.


Of course, this is true. Although this does turn in to a having cake
and eating it argument.

The whole point of autoboxing is that it is automatic, and doesn't
require programmer annotation.

There are a lot of things like this in Java. The automation of GC for
example, can lead you to leave large numbers of objects dangling on a
static variable (been there, done that...)

Cheers

Phil

 

[Tim Tyler]

Tim Tyler wrote:

IMO, autoboxing sucks.

AFAICS, it's only good if your point of comparison is the previous version
of Java.

Take a slightly less myopic perspective - and surely the best thing is
never to have had primitive types in the first place.

I'd view that as a myopic perspective. Java wouldn't be appropriate for
certain high-performance applications if that were true. [...]

That appears to be the idea that having no primitive types necessarily
involves a performance hit.

Performance may have been one of the reasons why primitive types were
included in Java in the first place - but I think these days the idea
that having everything be an object involves a performance hit is
regarded as a fallacy.

Essentially, a JIT should be capable of massaging a program into
a functionally equivanent form, and whether things are objects
or not internally becomes largely irrelevant at that stage.

That's not to say Java's designers made a mistake here - Java got
enough criticism about performance at the time - and given the
state of JIT technology at the time, having no primitive types
would probably have made things worse initially.

However the decision of Java's designers had the effect of
prioritising short term performance considerations over Java's
longevity.

Their design decision never got fixed - and now Java appears
to be stuck forever with primitive types - and it's a factor
that looks likely to be significantly implicated in Java's demise.

 

[Tim Tyler]

For Integers, I think it has a pool of all ints from 0 to 1000 or
somesuch to optimize commonly used numbers.

Java 5 caches integers smaller than 128 and bigger than -129.

Earlier versons do not - leading to non-backwards-compatible behaviour:

``Immutable Objects

Consider the following code fragment:

Integer i1 = 100;
Integer i2 = 100;
Integer i3 = 1000;
Integer i4 = 1000;
System.out.println(i1==i2);
System.out.println(i3==i4);

Can you guess what will be printed on the screen? If your
answer is false--well, you're wrong.

In this case, J2SE 5.0 works differently. Certain ranges of
values are stored as immutable objects by the Java Virtual
Machine. So, in this case, the output is:

true
false

Normally, when the primitive types are boxed into the
wrapper types, the JVM allocates memory and creates a new
object. But for some special cases, the JVM reuses the same
object.

The following is the list of primitives stored as immutable
objects:

* boolean values true and false
* All byte values
* short values between -128 and 127
* int values between -128 and 127
* char in the range \u0000 to \u007F''

- http://today.java.net/pub/a/today/2005/03/24/autoboxing.html

 

[Bent C Dalager]

Java 5 caches integers smaller than 128 and bigger than -129.

Earlier versons do not - leading to non-backwards-compatible behaviour:

Which earlier versions? 1.5 betas and release candidates? 1.4.x
doesn't have autoboxing, so Integer caching shouldn't be an issue
there.

Cheers
Bent D

 

[ridvansg]

I come from the world of C++ which is full with templates, belive me
templates are everything but not cool, they are aproppriate for a
language like perl but not java.

Just my opinion

 

[Lee Fesperman]

I /very much/ doubt whether Java with Smalltalk/LISP style integers would be
any less suitable for implementing an RDMS.

To me, this looks like pure conjecture on your part. I know of at least 5 non-trivial
RDBMSs implemented in pure Java. I don't know of any implemented in Smalltalk or Lisp.

Of course, I could be wrong -- perhaps your DB's efficiency is dominated by
numeric calculations (rather than by disk-seeks and other IO), but if so then
I'd say there something Very Wrong with your DB...

Disk I/O is not necessarily an issue since the DB also has an in-memory mode.

Is your "Very Wrong" comment based on doing a non-trivial implementation of an RDBMS?
Perhaps you could explain.

 

[Lee Fesperman]

Tim Tyler wrote:

IMO, autoboxing sucks.

AFAICS, it's only good if your point of comparison is the previous version
of Java.

Take a slightly less myopic perspective - and surely the best thing is
never to have had primitive types in the first place.

I'd view that as a myopic perspective. Java wouldn't be appropriate for
certain high-performance applications if that were true. [...]

That appears to be the idea that having no primitive types necessarily
involves a performance hit.
True.

Performance may have been one of the reasons why primitive types were
included in Java in the first place - but I think these days the idea
that having everything be an object involves a performance hit is
regarded as a fallacy.

Do you have evidence of significant high performance applications written in such a
language?

Essentially, a JIT should be capable of massaging a program into
a functionally equivanent form, and whether things are objects
or not internally becomes largely irrelevant at that stage.

Obviously, I have doubts that it is true in *all* cases. One area I mentioned was heavy
use of dynamic loading.

Their design decision never got fixed - and now Java appears
to be stuck forever with primitive types - and it's a factor
that looks likely to be significantly implicated in Java's demise.

Ultimately, that may be true, but I don't think that is a widely held belief in relation
to a truly general purpose language.

 

[Antti S. Brax]

Antti> (e-mail address removed) wrote in comp.lang.java.programmer:
Joseph> On second thought, perhaps Generics simply provides javac
Joseph> the information it needs to implement autoboxing.

Antti> No. There are only assumptions.

The information that you need for autoboxing is there.

Actually, not quite, as I left the cast out which should have been
there.



Antti> In the second case you do not know what comes out of
Antti> the collection. You only _assume_ it is a boolean,
Antti> since the programmer wants one.

Yes. But we are talking about autoboxing here. There is no requirement
for autoboxing to be type safe.

Correct. But then, there is no requirement for a programming
language to be type safe either.

And I was not challenging type safety or whether autoboxing
should be type safe. Only pointing out that in the example
code of the original article there were no facts involved,
only assumptions.

 

[Chris Uppal]

Lee Fesperman wrote [quoted in full for reasons that will become evident]:

To me, this looks like pure conjecture on your part. I know of at least 5
non-trivial RDBMSs implemented in pure Java. I don't know of any
implemented in Smalltalk or Lisp.


Disk I/O is not necessarily an issue since the DB also has an in-memory
mode.

Is your "Very Wrong" comment based on doing a non-trivial implementation
of an RDBMS? Perhaps you could explain.

I can't be bothered with this.

-- chris

 

[Lee Fesperman]

Lee Fesperman wrote [quoted in full for reasons that will become evident]:

Is your "Very Wrong" comment based on doing a non-trivial implementation
of an RDBMS? Perhaps you could explain.

I can't be bothered with this.

Right, I figured you couldn't back up your rash comment.

 

[Murat Tasan]

i'm not sure how much performance loss is done, but even the people at Sun
themselves make a point of saying not to use autoboxing/unboxing for
high-performance apps.

i just wrote a little test program that loops through and performs a
single addition to an integer 10 million times.

using a primitive integer, the loop takes on average just about 100
milliseconds.

rewriting the program to represent the integer as an Integer object, then
leaving the rest of the loop as it is for the autoboxing/unboxing, the
loop now takes on average about 2000 milliseconds. thats 20x slower!

then i rewrote the program again to store the cumulative result back in
the original primitive type, but now i'm constantly to that primitive type
an Integer object. this experiment should test for unboxing, rather than
both. the average time is about 150 milliseconds.

this indicated that the boxing is what takes a long time. so... i wrote
one final program that only does the boxing by storing the results of an
operation with two primitive types into an Integer object. the results
were once again an average time of well over 1000 milliseconds.

so, the lesson from this is that unboxing is relatively cheap and easy and
can be used in your app even if performance is a consideration. if many
autoboxes are going to occur however, consider using primitive types
instead.

hope this helps a bit.

murat

 

[Tim Tyler]

Which earlier versions?

All earlier versions.

1.5 betas and release candidates? 1.4.x doesn't have autoboxing, so
Integer caching shouldn't be an issue there.

Exactly: in the supplied [but snipped :-(] example, Java 5 behaves
differently from all previous versions of Java - in a manner that is
not backwards-compatible with them.