Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Eric Sosman <esosman@comcast-dot-net.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: Autoboxing and Performance ?
Date: Tue, 20 Aug 2013 08:08:33 -0400
Organization: A noiseless patient Spider
Lines: 101
Message-ID: <kuvm84$11g$1@dont-email.me>
References: <fcudnTCLD6xZ3I7PnZ2dnUVZ_gadnZ2d@giganews.com> <wbsfj3kz9x6.1hthr4dxr2yvl$.dlg@40tude.net> <cLydnRPXuKJn2I7PnZ2dnUVZ_jydnZ2d@giganews.com> <slrnl16i32.q59.avl@gamma.logic.tuwien.ac.at> <Wt2dnWWN8Yvf0I7PnZ2dnUVZ_r2dnZ2d@giganews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 20 Aug 2013 12:08:36 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="0d73d8cc209bff1c6395088b400d0605"; logging-data="1072"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+vnfk33m6Xhmye7CpEen8B"
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
In-Reply-To: <Wt2dnWWN8Yvf0I7PnZ2dnUVZ_r2dnZ2d@giganews.com>
Cancel-Lock: sha1:oavkmCbfA9RE/9pp4btNWALHmYc=
Xref: csiph.com comp.lang.java.programmer:25069

On 8/20/2013 7:04 AM, Peter Olcott wrote:
> On 8/20/2013 5:43 AM, Andreas Leitgeb wrote:
>> Peter Olcott <OCR4Screen> wrote:
>>> On 8/20/2013 5:20 AM, Joerg Meier wrote:
>>>> On Tue, 20 Aug 2013 05:15:30 -0500, Peter Olcott wrote:
>>>>
>>>>>    From Java A Beginner's Guide, Fifth Edition by Herbert Schildt,
>>>>> page 425:
>>>>
>>>>> class AutoBox3 {
>>>>>      public static void main(String args[]) {
>>>>>      Integer iOb;
>>>>>      iOb = 99;
>>>>
>>>>> // The following automatically unboxes iOb,
>>>>> // performs the increment, and then reboxes
>>>>> // the result back into iOb
>>>>> ++iOb;
>>>>
>>>>> It seems to me that all this unboxing and reboxing is a complete waste
>>>>> of CPU time. It would make much more sense to provide an
>>>>> Integer.Increment() member function that directly operates on the
>>>>> contained data.
>>>>
>>>>> Why does Java waste so much CPU resources with its unboxing and
>>>>> reboxing
>>>>> in cases such as this, and not simply provide member functions that
>>>>> directly operate on the contained data?
>>>>
>>>> Because IntegerS and other Number classes are immutable. The
>>>> contained data
>>>> is not allowed to be changed under any circumstances.
>>>>
>>>> Liebe Gruesse,
>>>>         Joerg
>>>>
>>>
>>> So the original object is replaced with a new object?
>>>
>>> What is the benefit (of immutability) that is worth the cost of this
>>> poor performance?
>>
>> The lesson probably should be, that if you intend to do math on
>> a variable, that you should use the primitive types instead.
>>
>>   class NoAutoBox {
>>       public static void main(String args[]) {
>>          int iOb;
>>          iOb = 99;
>>          ++iOb; // value is overwritten; no objects created.
>>       }
>>   }
>>
>> PS: doing math on them is not the only use for integral numeric types.
>>
>
> I am trying to understand the Java language design principles that are
> underlying the reasoning why there is such a thing as unboxing and
> reboxing. I can see why class objects should be kept in a box, no
> unboxing or reboxing required.
>
> I do not see why primitive objects must be kept in a box, or why they
> must be unboxed and reboxed if they are to be operated upon.

     There's no "must," there's a "may."

     At a low level Java cannot do arithmetic with Integer (or
Long or ...) objects, but only with int (long, ...) primitive
values.  And in the early days this was explicit: In order to
perform the increment in your example, you had to write

	Integer iOb = Integer.valueOf(99);
	iOb = Integer.valueOf(iOb.intValue() + 1);

... or something in that vein.  Boxing and unboxing just amount
to the compiler writing the boiler-plate for you; the same stuff
is still going on behind the scenes.

     So, why have Integer (Long, ...) objects in the first place?
Because there are contexts where you *must* have an object instance,
and a primitive value will not do.  For example, an ArrayList cannot
hold primitives, only object references.  The keys and values in a
HashMap cannot be primitives, only object references.  You cannot
synchronize on a primitive value, you cannot set a primitive to
`null', you cannot apply the `instanceof' operator to a primitive,
and the list goes on.  That's what Integer and its pals are for:
When you you want to use a value in a context that needs an object.

     IMHO boxing and unboxing are snares of Satan, creating more
confusion (e.g., this thread!) and trouble than they're worth.
The deeper problem, it seems to me, is that Java is unable to treat
a primitive the same way it treats an object: Why *shouldn't* you
be able to put 3.14159 in an ArrayList, or ask whether it is an
`instanceof short'?  However, the primitive-vs-reference chasm is
a deep divide in the design of Java, and there seems little chance
that it could ever go away.  Boxing and unboxing bridge the chasm,
but the bridge is rickety and you should tread it with care.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid