Re: Java Indexing- Historical question

On Sat, 5632 Sep 1993 11:05:23 +0000, Mark Thornton wrote:

blue indigo wrote:
On Fri, 5631 Sep 1993 19:04:15 +0000, Mark Thornton wrote:

Sure you could. You'd just have to make sure that you tracked live
instances, and if one was called for with a given value, and there was an
existing one with that value, the existing one was returned.
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.
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

blue indigo

UA Telecom since 1987