By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,034 Members | 822 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,034 IT Pros & Developers. It's quick & easy.

Autoboxing and java.lang.Math

P: n/a
Hello!

In JDK1.5 Sun has introduced autoboxing. The user does not need to
convert an instance of Integer into an int herself anymore when she
wants to do arithmetic operations with the int. The compiler takes
care of the required conversion. I like this approach since it
preserves the efficiency of primitive data types but lets the user
believe she were dealing with objects.

Now it would be nice to be consequent and move the methods from
java.lang.Math into the respective Number classes. Then, for example,
you could say:

int i = 9;
double root = i.sqrt();

In this case the compiler would convert the second line as
appropriate:

int i = 9;
double root = Math.sqrt(i);

Well, and then it would be nice if you could redefine operators ...
I'm not sure the guys at Sun knew what could break lose if they
introduce this autoboxing stuff ;-). I would be interesting in hearing
some comments about this idea. Comments saying this is crazy are
welcome. I just want to converse the issue a bit.

Regards, Oliver Plohmann
Jul 17 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Oliver Plohmann wrote:
Hello!

In JDK1.5 Sun has introduced autoboxing. The user does not need to
convert an instance of Integer into an int herself anymore when she
wants to do arithmetic operations with the int. The compiler takes
care of the required conversion. I like this approach since it
preserves the efficiency of primitive data types but lets the user
believe she were dealing with objects.
IMHO, no efficiency is preserved. The compiler inserts the same method
calls and constructions as if one were to write it by hand. Note that
the JVM knows nothing about autoboxing, it is all a compiler trick, like
inner classes.

In fact, I suspect this will lead to more inefficient code; e.g. when
you have to create the Integers by hand, you might notice that you
create the same one multiple times and introduce a variable. This is
less likely to happen with autoboxing turning things into Integers
implicitly. (Admittedly this is a fault of the programmer.)

Now it would be nice to be consequent and move the methods from
java.lang.Math into the respective Number classes. Then, for example,
you could say:

int i = 9;
double root = i.sqrt();

In this case the compiler would convert the second line as
appropriate:

int i = 9;
double root = Math.sqrt(i);

In this case it would probably make more sense to implement
Integer.sqrt() rather than do compiler manipulations.
Well, and then it would be nice if you could redefine operators ...
I'm not sure the guys at Sun knew what could break lose if they
introduce this autoboxing stuff ;-).
Redefining operators seems like quite a leap from autoboxing to me.
I would be interesting in hearing
some comments about this idea. Comments saying this is crazy are
welcome. I just want to converse the issue a bit.


Ray

--
XML is the programmer's duct tape.
Jul 17 '05 #2

P: n/a
Raymond DeCampo <rd******@spam.twcny.spam.rr.spam.com.spam> wrote in message news:<8x*******************@twister.nyroc.rr.com>. ..
Oliver Plohmann wrote:
Hello!

In JDK1.5 Sun has introduced autoboxing. The user does not need to
convert an instance of Integer into an int herself anymore when she
wants to do arithmetic operations with the int. The compiler takes
care of the required conversion. I like this approach since it
preserves the efficiency of primitive data types but lets the user
believe she were dealing with objects.
IMHO, no efficiency is preserved. The compiler inserts the same method
calls and constructions as if one were to write it by hand. Note that
the JVM knows nothing about autoboxing, it is all a compiler trick, like
inner classes.


I did not express myself clearly enough here. What I meant is that the
use of wrapper classes, while the computation itself is done based on
primitive data types, is more efficient compared to computations where
numbers are instances of classes (e.g. real objects as in Smalltalk).
In fact, I suspect this will lead to more inefficient code; e.g. when
you have to create the Integers by hand, you might notice that you
create the same one multiple times and introduce a variable. This is
less likely to happen with autoboxing turning things into Integers
implicitly. (Admittedly this is a fault of the programmer.)

Now it would be nice to be consequent and move the methods from
java.lang.Math into the respective Number classes. Then, for example,
you could say:

int i = 9;
double root = i.sqrt();

In this case the compiler would convert the second line as
appropriate:

int i = 9;
double root = Math.sqrt(i);


In this case it would probably make more sense to implement
Integer.sqrt() rather than do compiler manipulations.


Yes, that's what I meant by saying "... move the methods from
java.lang.Math into the respective Number classes".

/Oliver
Well, and then it would be nice if you could redefine operators ...
I'm not sure the guys at Sun knew what could break lose if they
introduce this autoboxing stuff ;-).


Redefining operators seems like quite a leap from autoboxing to me.
I would be interesting in hearing
some comments about this idea. Comments saying this is crazy are
welcome. I just want to converse the issue a bit.


Ray

Jul 17 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.