Java Indexing- Historical question

[blue indigo]

Mark Thornton wrote:
Boxing of primitives costs memory too. The ability to eliminate the
boxing involved in Integer[] vs int[] is still a long way off (and may
require a change in the language so that
new Integer.valueOf(x) == Integer.valueOf(x) for all x).
You mean "so that mew Integer(x) == Integer.valueOf(x) for all x", do
you not?

You mean "so that new Integer(x) == Integer.valueOf(x) for all x", do
you not?

No, because outside a small range Integer.valueOf(x) is implements as
new Integer(x).

Eh -- I was correcting the spelling. What are you suggesting, just that
Integer.valueOf(x) == Integer.valueOf(x)? That's much more workable as it
doesn't mess with the semantics of new.

This is just too expensive.

Not if it's implemented smart, by making the Integer object an "int with
methods" rather than really a reference type. It's immutable so it won't
alter program semantics. The only slightly-tricky bit is locking. If an
instance is ever synchronized, some proxy object has to be locked, and it
must be associated with the integer value in a hashmap somewhere. This can
be lazily created the first time the value is synchronized on. Then the
tricky bit becomes cleaning deadwood out of the same hashmap, as even
using a weak hash map the integer key would not get collected. But
unlocking the integer can remove the mapping if the lock count just went
to zero.

 

[Mark Thornton]

Not if it's implemented smart, by making the Integer object an "int with
methods" rather than really a reference type. It's immutable so it won't
alter program semantics.

There may exist some applications which rely on the fact that new
Integer(1) != new Integer(1). It would change the semantics of those
applications unless the Java specification is changed. If it was changed
so that == and equals() were identical for Integer (and some other
types) then optimising these types would become possible.

Mark Thornton

 

[blue indigo]

There may exist some applications which rely on the fact that new
Integer(1) != new Integer(1).

I'd hope they're rare. Actually, I was thinking that the public Integer
constructors should be deprecated in favor of valueOf().

It would change the semantics of those
applications unless the Java specification is changed. If it was changed
so that == and equals() were identical for Integer (and some other
types) then optimising these types would become possible.

Another alternative is to make the nature of an "Integer" depend on
whether it was obtained with valueOf() or with new Integer(). The former
could store as the actual integer value, with the compiler generating
appropriate bytecodes, and the latter as the same sort of object as now.
The tricky bit here is knowing which is which when passing one around as
an argument or return value. Most likely you'd need to have two types
under the hood, Integer and (say) OptimizedInteger, even where the Java
source only has Integer, with the VM knowing how to treat the latter and
auto(un)boxing occurring when the two types come into contact with one
another.