Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #25064 > unrolled thread

Autoboxing and Performance ?

Back to article view | Back to comp.lang.java.programmer

Contents

  Autoboxing and Performance ? Peter Olcott <OCR4Screen> - 2013-08-20 05:15 -0500
    Re: Autoboxing and Performance ? Joerg Meier <joergmmeier@arcor.de> - 2013-08-20 12:20 +0200
      Re: Autoboxing and Performance ? Peter Olcott <OCR4Screen> - 2013-08-20 05:33 -0500
        Re: Autoboxing and Performance ? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-08-20 10:43 +0000
          Re: Autoboxing and Performance ? Peter Olcott <OCR4Screen> - 2013-08-20 06:04 -0500
            Re: Autoboxing and Performance ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-20 08:08 -0400
            Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-20 20:15 -0400
        Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-20 20:12 -0400
        Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-21 03:52 +0300
          Re: Autoboxing and Performance ? Sebastian <news@seyweiler.dyndns.org> - 2013-08-21 07:27 +0200
            Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-21 18:43 -0400
              Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-22 08:08 +0300
            Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-22 07:56 +0300
              Re: Autoboxing and Performance ? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-08-22 10:51 -0700
                Re: Autoboxing and Performance ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-08-22 19:36 +0000
                  Re: Autoboxing and Performance ? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-08-22 13:01 -0700
                  Re: Autoboxing and Performance ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-08-22 21:19 +0000
                    Re: Autoboxing and Performance ? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-08-22 14:39 -0700
                      Re: Autoboxing and Performance ? markspace <markspace@nospam.nospam> - 2013-08-22 19:50 -0700
                        Re: Autoboxing and Performance ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-08-23 23:16 +0000
                          Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-24 17:20 +0300
                    Re: Autoboxing and Performance ? Lew <lewbloch@gmail.com> - 2013-08-23 11:08 -0700
                      Re: Autoboxing and Performance ? Joerg Meier <joergmmeier@arcor.de> - 2013-08-23 22:52 +0200
                        Re: Autoboxing and Performance ? Jim Gibson <jimsgibson@gmail.com> - 2013-08-23 16:38 -0700
                  Re: Autoboxing and Performance ? "John B. Matthews" <nospam@nospam.invalid> - 2013-08-23 06:17 -0400
                    Re: Autoboxing and Performance ? Jeff Higgins <jeff@invalid.invalid> - 2013-08-23 17:25 -0400
                    Re: Autoboxing and Performance ? Jeff Higgins <jeff@invalid.invalid> - 2013-08-25 18:34 -0400
                      Re: Autoboxing and Performance ? Jeff Higgins <jeff@invalid.invalid> - 2013-08-28 10:52 -0400
                  Re: Autoboxing and Performance ? Martin Gregorie <martin@address-in-sig.invalid> - 2013-08-23 23:37 +0000
          Re: Autoboxing and Performance ? Robert Klemme <shortcutter@googlemail.com> - 2013-08-26 19:33 +0200
            Re: Autoboxing and Performance ? Sven Köhler <remove-sven.koehler@gmail.com> - 2013-08-29 10:09 +0300
              Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-29 14:14 +0200
        Re: Autoboxing and Performance ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-08-29 21:28 -0300
    Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-20 20:03 +0200
      Re: Autoboxing and Performance ? Lew <lewbloch@gmail.com> - 2013-08-20 16:23 -0700
        Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-21 11:51 +0200
          Re: Autoboxing and Performance ? Lew <lewbloch@gmail.com> - 2013-08-21 08:39 -0700
            Re: Autoboxing and Performance ? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-08-21 16:51 +0100
          Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-21 19:19 -0400
            Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-22 09:49 +0200
      Re: Autoboxing and Performance ? Jan Burse <janburse@fastmail.fm> - 2013-08-21 11:54 +0200
    Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-20 20:06 -0400
      Re: Autoboxing and Performance ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-20 21:19 -0400
        Re: Autoboxing and Performance ? Joerg Meier <joergmmeier@arcor.de> - 2013-08-21 10:05 +0200
          Re: Autoboxing and Performance ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-21 07:19 -0400
            Re: Autoboxing and Performance ? Joerg Meier <joergmmeier@arcor.de> - 2013-08-22 00:18 +0200
              Re: Autoboxing and Performance ? Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-08-21 19:58 -0400
          Re: Autoboxing and Performance ? Lew <lewbloch@gmail.com> - 2013-08-21 08:36 -0700
        Re: Autoboxing and Performance ? taqmcg@gmail.com - 2013-08-21 09:37 -0700
    Re: Autoboxing and Performance ? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-08-20 23:28 -0500
    Re: Autoboxing and Performance ? lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-08-21 10:09 +0100
      Re: Autoboxing and Performance ? Arne Vajhøj <arne@vajhoej.dk> - 2013-08-21 19:04 -0400
        Re: Autoboxing and Performance ? Arivald <NOSPAMarivald@interia.pl> - 2013-08-22 07:39 +0200
    Re: Autoboxing and Performance ? Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-08-29 01:42 -0300

Page 3 of 3 — ← Prev page 1 2 [3]

#25089

A little up in the source code one finds also:

     /**
      * Cache to support the object identity semantics of
      * autoboxing for values between -128 and 127 (inclusive)
      * as required by JLS.
      *
      * The cache is initialized on first usage.  The size of the cache
      * may be controlled by the -XX:AutoBoxCacheMax=<size> option.


> P.S.: Here is the JDK 1.7.25 source code of Integer.valueOf:
>
>     /**
>       * Returns an {@code Integer} instance representing the specified
>       * {@code int} value.  If a new {@code Integer} instance is not
>       * required, this method should generally be used in preference to
>       * the constructor {@link #Integer(int)}, as this method is likely
>       * to yield significantly better space and time performance by
>       * caching frequently requested values.
>       *
>       * This method will always cache values in the range -128 to 127,
>       * inclusive, and may cache other values outside of this range.
>       *
>       * @param  i an {@code int} value.
>       * @return an {@code Integer} instance representing {@code i}.
>       * @since  1.5
>       */
>      public static Integer valueOf(int i) {
>          assert IntegerCache.high >= 127;
>          if (i >= IntegerCache.low && i <= IntegerCache.high)
>              return IntegerCache.cache[i + (-IntegerCache.low)];
>          return new Integer(i);
>      }
>
>

[toc] | [prev] | [next] | [standalone]

#25076

On 8/20/2013 6:15 AM, 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;

Awful code.

Hungarian notation is not used in Java.

There are no reason to use Integer instead of int
in this case.

> It seems to me that all this unboxing and reboxing is a complete waste
> of CPU time.

If you need to convert between a ref and a value type then it
is necessary.

But you don't need to in the above code.

>                      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?

That was how thing were designed.

Typical you would use simple data types if you want to do
arithmetic operations in Java.

And even the case without matching simple type BigInteger and BigDecimal
are immutable.

It could have been designed different, but that does not change how
it was designed.

Arne

[toc] | [prev] | [next] | [standalone]

#25082

On 8/20/2013 8:06 PM, Arne Vajhøj wrote:
>[...]
> And even the case without matching simple type BigInteger and BigDecimal
> are immutable.
>
> It could have been designed different, but that does not change how
> it was designed.

     Observe that immutability allows an optimization:

	Integer v1 = 42;
	Integer v2 = 42;

... is equivalent to

	Integer v1 = Integer.valueOf(42);
	Integer v2 = Integer.valueOf(42);

... and both v1 and v2 can refer to the same Integer object.
(For sufficiently small values, Java in fact guarantees that
they will.)  If Integer were mutable, then a following `++v2'
would change v1 as well.  That's probably undesirable (my
dating site increments boyCount and discovers that girlCount
has also increased, even though no girls have signed up,[*]
so the valueOf() equivalence would have to be replaced by

	Integer v1 = new Integer(42);
	Integer v2 = new Integer(42);

... instead, so v1 and v2 could have independent existences and
independent values.  That is, mutability would require *more*
object creation/collection, not less.

     Can this be true?  Yes, absolutely.  A few months ago, someone
in this forum wrote of "optimizing" a Map<Something,Integer> by writing
a mutable Counter class of his own (I've played fast and loose with
class names I no longer recall exactly).  Instead of

	Integer count = map.get(thing);
	if (count == null) {
	    map.put(thing, 1);
	else {
	    map.put(thing, count + 1);
	}

... he had

	Counter count = map.get(thing);
	if (count == null) {
	    map.put(new Counter(1));
	} else {
	    count.increment(1);
	}

Guess what?  His memory usage *increased*, dramatically!  There
were many hundreds of thousands of entries in the Map, most of
them with smallish counts -- hence, most of them referring to the
same few Integer instances.  By giving every single entry its very
own mutable Counter instead, he vastly increased the number of
object instances in play, to the point of OutOfMemoryError!

     Nonetheless, I'm still of the opinion that autoboxing is Satan's
work.  Another thread, somewhat further back, wondered why this
apparently thread-safe code wasn't thread-safe at all:

	class Whatever {
	    private static Integer counter;
	    void someMethod() {
	        synchronized(counter) {
	            ++counter;
	            ...
	        }
	    }
	    ...
	}

I believe that if he had been compelled to write

	counter = Integer.valueOf(counter.intValue() + 1);

... he would never have made that particular mistake -- and I
strongly suspect that others have made the same error, but just
haven't discovered it yet ...

     [*] No, lads: That's not an advantage.[**]

     [**] No girls have signed up but my site thinks otherwise,
          so your blind date is named Ralph.

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

[toc] | [prev] | [next] | [standalone]

#25086

On Tue, 20 Aug 2013 21:19:36 -0400, Eric Sosman wrote:

>      Nonetheless, I'm still of the opinion that autoboxing is Satan's
> work.  Another thread, somewhat further back, wondered why this
> apparently thread-safe code wasn't thread-safe at all:

> 	class Whatever {
> 	    private static Integer counter;
> 	    void someMethod() {
> 	        synchronized(counter) {
> 	            ++counter;
> 	            ...
> 	        }
> 	    }
> 	    ...
> 	}

I still don't see how that wouldn't be thread-safe, could you elaborate ?
Or are we to assume other code touches counter without being in a
synchronized(counter) block itself in this example ?

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#25091

On 8/21/2013 4:05 AM, Joerg Meier wrote:
> On Tue, 20 Aug 2013 21:19:36 -0400, Eric Sosman wrote:
>
>>       Nonetheless, I'm still of the opinion that autoboxing is Satan's
>> work.  Another thread, somewhat further back, wondered why this
>> apparently thread-safe code wasn't thread-safe at all:
>
>> 	class Whatever {
>> 	    private static Integer counter;
>> 	    void someMethod() {
>> 	        synchronized(counter) {
>> 	            ++counter;
>> 	            ...
>> 	        }
>> 	    }
>> 	    ...
>> 	}
>
> I still don't see how that wouldn't be thread-safe, could you elaborate ?
> Or are we to assume other code touches counter without being in a
> synchronized(counter) block itself in this example ?

     The `counter' variable is not an Integer object, but a
reference to an Integer object.  The `++counter' line brings
a second Integer into the picture, and makes `counter' refer
to that new Integer instead of to the original.  However, the
block is still synchronized on the first one; it doesn't
somehow magically re-synchronize on the second.

     Assume `counter' points to Integer.valueOf(0) initially
(I ought to have showed the initialization in the snippet;
sorry).  Then with threads T1 and T2 executing:

	T1: synchronized(counter)  // locks the 0 object
	T1: ... now in critical section ...
	T1: ++counter;  // counter now points to the 1 object
	T1: ... still in critical section ...
	T2: synchronized(counter)  // locks the *1* object
	T2: ... now in critical section ...

Both T1 and T2 are now in the synchronized block simultaneously,
holding the locks of two different Integer objects.

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

[toc] | [prev] | [next] | [standalone]

#25096

On Wed, 21 Aug 2013 07:19:06 -0400, Eric Sosman wrote:

>      The `counter' variable is not an Integer object, but a
> reference to an Integer object.  The `++counter' line brings
> a second Integer into the picture, and makes `counter' refer
> to that new Integer instead of to the original.  However, the
> block is still synchronized on the first one; it doesn't
> somehow magically re-synchronize on the second.

Right, of course. I feel silly now. I only thought about how the whole
unboxing and reboxing was in the synchronized block, and completely
disregarded how it would affect other synchronized blocks.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#25100

On 8/21/2013 6:18 PM, Joerg Meier wrote:
> On Wed, 21 Aug 2013 07:19:06 -0400, Eric Sosman wrote:
>
>>       The `counter' variable is not an Integer object, but a
>> reference to an Integer object.  The `++counter' line brings
>> a second Integer into the picture, and makes `counter' refer
>> to that new Integer instead of to the original.  However, the
>> block is still synchronized on the first one; it doesn't
>> somehow magically re-synchronize on the second.
>
> Right, of course. I feel silly now. I only thought about how the whole
> unboxing and reboxing was in the synchronized block, and completely
> disregarded how it would affect other synchronized blocks.

     If it's a trap that can snare Joerg Meier, it's a trap that
*will* ensnare and *has* ensnared uncounted less clueful people.

     Dante tells us that Heretics populate the sixth circle of
Hell.  Sounds like a good home for the inventors of autoboxing,
whose heresy was to confound objects and primitives when such
confoundings create confusion.  Confusion to them! say I.

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

[toc] | [prev] | [next] | [standalone]

#25092

Joerg Meier wrote:
> Eric Sosman wrote:
>>      Nonetheless, I'm still of the opinion that autoboxing is Satan's
>> work.  Another thread, somewhat further back, wondered why this
>> apparently thread-safe code wasn't thread-safe at all:
>
>> 	class Whatever {
>> 	    private static Integer counter;
>> 	    void someMethod() {
>> 	        synchronized(counter) {
>> 	            ++counter;
>> 	            ...
>> 	        }
>> 	    }
>> 	    ...
>> 	}
>
> I still don't see how that wouldn't be thread-safe, could you elaborate ?

A monitor has to be the same object between threads. Holding a "lock" on two 
different objects actually doesn't lock anything.

> Or are we to assume other code touches counter without being in a

If 'counter' changes to point to a different object, as in the sample code 
here, then it no longer points to the object holding the monitor, which 
makes it useless as a lock.

> synchronized(counter) block itself in this example ?

The finger is not the moon.

That means a pointer is not the same thing as the object to which it points.

Locks are taken on objects, not pointers.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#25095

On Tuesday, August 20, 2013 9:19:36 PM UTC-4, Eric Sosman wrote:
...
> work.  Another thread, somewhat further back, wondered why this
> apparently thread-safe code wasn't thread-safe at all:
> 
> 	class Whatever {
> 	    private static Integer counter;
> 	    void someMethod() {
> 	        synchronized(counter) {
> 	            ++counter;
> 	            ...
> 	        }
> 	    }
> 	    ...
> 	}
> 
> I believe that if he had been compelled to write
> 
> 	counter = Integer.valueOf(counter.intValue() + 1);
> 
> ... he would never have made that particular mistake -- and I 

Off topic, but my idiosyncratic view is that part of the problem here is the use of the increment and decrement operators.  Personally I find that their use often leads to confusing code.  Had the code been written
       counter += 1;
then the '=' might help the coder have better intuition that something new was being assigned to counter rather than a modification the existing value.  Of course your example makes that even more apparent, so this doesn't refute the 'evil' of autoboxing.

My objection to these operators is primarily that they seemed intended to promote code which uses side effects (e.g., why do we have i++ and ++i) but I'm happy to have another reason to deplore them.  

   Regards,
   Tom McGlynn

[toc] | [prev] | [next] | [standalone]

#25083

On 8/20/2013 5:15 AM, 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.

Adding that would require that the class be mutable. However, mutability 
kills a lot of optimizations. For example, immutable classes get thread 
safety for free. In the specific case of boxed integers, the 
immutability allows the compiler to elide the boxing and unboxing in 
certain cases. So it's not at all clear that giving you that .increment 
function would actually make your code faster.

> 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?

The optimizer in the Java VM is capable of eliminating boxes if it finds 
it doesn't need them, so it's likely not even wasting any CPU resources 
at all. Even if it can't eliminate the boxes, it can fast-path code into 
a branch-and-subtraction/addition for an unbox/box, respectively.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#25087

On 20/08/13 11:15, 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?

I think a better question might be "why have primitives in the first place'

When everything else is an Object does it really encourage clarity of 
thought and cohesion of design to pollute the Object Oriented paradigm 
with primitives.

If there were no primitives then autoboxing would be a non-issue


... and before anyone gets excited and starts talking about components 
that only deal with primitives, if they didn't exist in the first place 
etc etc

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
GNU/Linux user #560883 - http://www.linuxcounter.net

[toc] | [prev] | [next] | [standalone]

#25098

On 8/21/2013 5:09 AM, lipska the kat wrote:
> On 20/08/13 11:15, 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?
>
> I think a better question might be "why have primitives in the first place'
>
> When everything else is an Object does it really encourage clarity of
> thought and cohesion of design to pollute the Object Oriented paradigm
> with primitives.
>
> If there were no primitives then autoboxing would be a non-issue

We have boxing and unboxing due to the split in reference
types and value types.

In C# an int is an object, but they still have ref and val types and
therefore boxing and unboxing.

Do we need value types?

For a pretty big chunk of business apps, then we could live fine
without.

But there are other cases where we really value types. Typical
when dealing with large arrays.

Arne

[toc] | [prev] | [next] | [standalone]

#25103

W dniu 2013-08-22 01:04, Arne Vajhøj pisze:
> On 8/21/2013 5:09 AM, lipska the kat wrote:
>> On 20/08/13 11:15, Peter Olcott wrote:
>> I think a better question might be "why have primitives in the first
>> place'
>>
>> When everything else is an Object does it really encourage clarity of
>> thought and cohesion of design to pollute the Object Oriented paradigm
>> with primitives.
>>
>> If there were no primitives then autoboxing would be a non-issue
>
> We have boxing and unboxing due to the split in reference
> types and value types.
>
> In C# an int is an object, but they still have ref and val types and
> therefore boxing and unboxing.
>

Still, for me distinguishing reference and value types seems to be 
artificial.

I learn OO in C++, where any type (both primitive and objects) can be 
passed both by reference or by value, depending on current needs.

So for me all this boxing and val/ref types seems to be nuisance.

Yes, I learn that objects in many languages are reference only... But 
still I find it inconvenient sometimes.

-- 
Arivald

[toc] | [prev] | [next] | [standalone]

#25165

On 08/20/2013 07:15 AM, 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?

As a sidenote to your perfectly legitimate question, please avoid 
anything written by Herb Schildt. He's actually intelligent and 
well-informed, but his published material is generally dreck and 
unhelpful to both a novice and and an experienced developer who seeks to 
learn a new language.

AHS
-- 
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.java.programmer

csiph-web