You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Aristedes Maniatis <ar...@maniatis.org> on 2007/12/20 10:47:47 UTC

Re: svn commit: r605850 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne: ./ access/ access/jdbc/ access/types/ dba/ dba/openbase/ dba/oracle/ dba/sqlite/ dba/sqlserver/ exp/parser/ query/ reflect/ util/ wocompat/

On 20/12/2007, at 8:44 PM, torehalset@apache.org wrote:

> java 5: new Integer(int) -> Integer.valueOf(int)

Or we could start to use autoboxing and just use "int" where  
appropriate. Is valueOf recommended over new Integer() for speed or  
other reasons in Java 5?

Ari



-------------------------->
Aristedes Maniatis
phone +61 2 9660 9700
PGP fingerprint 08 57 20 4B 80 69 59 E2  A9 BF 2D 48 C2 20 0C C8



Autoboxing

Posted by Kevin Menard <km...@servprise.com>.
On 12/20/07 10:17 AM, "Andrus Adamchik" <an...@objectstyle.org> wrote:

> I agree with Tore... Autoboxing is a confusing solution for the legacy
> design holes in Java. It mostly obfuscates things. Having said that, I
> guess since it is an official language feature now, we should not
> prohibit its use in the Cayenne codebase. But making a special effort
> to use it throughout the code looks like a waste of time.

If that's how you guys feel, I'm not going to push the issue.  I do just
want to note that with IDEA I can change the whole codebase in 10 min.
though.  The inspections are quite good.

-- 
Kevin


Re: svn commit: r605850 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/ apache/cayenne: ./ access/ access/jdbc/ access/types/ dba/ dba/openbase/ dba/oracle/ dba/sqlite/ dba/sqlserver/ exp/parser/ query/ reflect/ util/ wocompat/

Posted by Andrus Adamchik <an...@objectstyle.org>.
I agree with Tore... Autoboxing is a confusing solution for the legacy  
design holes in Java. It mostly obfuscates things. Having said that, I  
guess since it is an official language feature now, we should not  
prohibit its use in the Cayenne codebase. But making a special effort  
to use it throughout the code looks like a waste of time.

Andrus


On Dec 20, 2007, at 4:48 PM, Tore Halset wrote:

> On Dec 20, 2007, at 14:35 , Kevin Menard wrote:
>
>> On 12/20/07 7:06 AM, "Tore Halset" <ha...@pvv.ntnu.no> wrote:
>>
>>>
>>> I am currently -1 to autoboxing, but Integer.valueOf(int) should not
>>> be a problem for anyone.
>>
>> Why is that?  I was just about to commit changes that replaces all  
>> of the
>> explicit unboxing and boxing code with autoboxing.  This would  
>> improve code
>> clarity in various places.
>
> It will make the code smaller, but will the code be clearer? As in  
> easier to understand?
>
>> Autoboxing yields nearly identical bytecode to manual boxing/unboxing
>> operations.  The only time I've found it's problematic is when you  
>> forget
>> what type you're working with to the point that you really should  
>> be using
>> the object type or the primitive type natively.
>
> I have been bitten by a couple of situations where I thought my  
> primitive type was primitive, but in fact had been autoboxed. This  
> is extra confusing when you have objects that have identical  
> methods, but with primitive and non primitive arguments. Like  
> List<Integer>.remove(int) and List<Integer>.remove(Integer) doing  
> two very different things. It is also a bit confusing when  
> autoboxing happens when you do not know about it. I do not have that  
> many good examples, but have googled some discussion around the  
> subject.
>
> http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/867001348831/r/448008648831
> http://www.theserverside.com/news/thread.tss?thread_id=27129
>
> Perhaps I can learn to like it over time :) What about you other guys?
>
> - Tore.
>
>


Re: svn commit: r605850 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/ apache/cayenne: ./ access/ access/jdbc/ access/types/ dba/ dba/openbase/ dba/oracle/ dba/sqlite/ dba/sqlserver/ exp/parser/ query/ reflect/ util/ wocompat/

Posted by Kevin Menard <km...@servprise.com>.
On 12/21/07 2:03 AM, "Tore Halset" <ha...@pvv.ntnu.no> wrote:

> On Dec 20, 2007, at 22:49 , Aristedes Maniatis wrote:
> 
>> I agree that it can be confusing in some cases, but it isn't like we
>> can just switch it off. The places where it is confusing is where it
>> happens without you realising it is happening.
> 
> Thanks, I have realized that now. It is not possible to get it turned
> off by not using it as it can pop up everywhere. So I rest my "-1" and
> are now a "+0" on this issue :)

There's actually an inspection in IDEA that will detect autoboxing so you
can undo it.  Granted, Eclipse is the development tool of choice for the
project, but I find it nice to float between the two.  In any event, if it
were a big problem, I could periodically scan the code base and deal with.

Sounds to me like it isn't all that necessary anyway, so this is more of an
FYI.

-- 
Kevin


Re: svn commit: r605850 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/ apache/cayenne: ./ access/ access/jdbc/ access/types/ dba/ dba/openbase/ dba/oracle/ dba/sqlite/ dba/sqlserver/ exp/parser/ query/ reflect/ util/ wocompat/

Posted by Tore Halset <ha...@pvv.ntnu.no>.
On Dec 20, 2007, at 22:49 , Aristedes Maniatis wrote:

> I agree that it can be confusing in some cases, but it isn't like we  
> can just switch it off. The places where it is confusing is where it  
> happens without you realising it is happening.

Thanks, I have realized that now. It is not possible to get it turned  
off by not using it as it can pop up everywhere. So I rest my "-1" and  
are now a "+0" on this issue :)

> The places where it makes the code easier to read (IMO) are when you  
> use it intentionally and might look like this:
>
> static public Integer SOME_CONSTANT = 5;
>
> But really, I think it a pretty minor issue.

Not that big win for me with a big monitor :)

> I wasn't aware of the speed enhancement of Integer.valueOf(int) and  
> that is pretty nice as long as we are sure those particular Integers  
> are immutable.


Integer is immutable. Autoboxing of ints probably uses  
Integer.valueOf(int).

  - Tore.


Re: svn commit: r605850 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/ apache/cayenne: ./ access/ access/jdbc/ access/types/ dba/ dba/openbase/ dba/oracle/ dba/sqlite/ dba/sqlserver/ exp/parser/ query/ reflect/ util/ wocompat/

Posted by Aristedes Maniatis <ar...@ish.com.au>.
On 21/12/2007, at 1:48 AM, Tore Halset wrote:

> I have been bitten by a couple of situations where I thought my  
> primitive type was primitive, but in fact had been autoboxed. This  
> is extra confusing when you have objects that have identical  
> methods, but with primitive and non primitive arguments. Like  
> List<Integer>.remove(int) and List<Integer>.remove(Integer) doing  
> two very different things. It is also a bit confusing when  
> autoboxing happens when you do not know about it. I do not have that  
> many good examples, but have googled some discussion around the  
> subject.
>
> http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/867001348831/r/448008648831
> http://www.theserverside.com/news/thread.tss?

I agree that it can be confusing in some cases, but it isn't like we  
can just switch it off. The places where it is confusing is where it  
happens without you realising it is happening. The places where it  
makes the code easier to read (IMO) are when you use it intentionally  
and might look like this:

static public Integer SOME_CONSTANT = 5;

But really, I think it a pretty minor issue. I wasn't aware of the  
speed enhancement of Integer.valueOf(int) and that is pretty nice as  
long as we are sure those particular Integers are immutable.

Ari


-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A



Autoboxing

Posted by Kevin Menard <km...@servprise.com>.


On 12/20/07 9:48 AM, "Tore Halset" <ha...@pvv.ntnu.no> wrote:

>> Why is that?  I was just about to commit changes that replaces all
>> of the
>> explicit unboxing and boxing code with autoboxing.  This would
>> improve code
>> clarity in various places.
> 
> It will make the code smaller, but will the code be clearer? As in
> easier to understand?

I certainly think so.  "new Character(b)"; "x.intValue()"; etc.  They all
detract from the core logic.  It'd really help the legibility of the ternary
expressions, IMHO.

I view boxing as a subclass of casting and think it's largely unnecessary.

> I have been bitten by a couple of situations where I thought my
> primitive type was primitive, but in fact had been autoboxed. This is
> extra confusing when you have objects that have identical methods, but
> with primitive and non primitive arguments. Like
> List<Integer>.remove(int) and List<Integer>.remove(Integer) doing two
> very different things. It is also a bit confusing when autoboxing
> happens when you do not know about it. I do not have that many good
> examples, but have googled some discussion around the subject.

Right, but then the question is are you really using the proper type in the
first place?  Calling intValue() may make things more explicit, but if
you're doing it enough where autoboxing is a problem, maybe you should be
using a primitive type to begin with.
 
> http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/867001348831/r
> /448008648831
> http://www.theserverside.com/news/thread.tss?thread_id=27129
> 
> Perhaps I can learn to like it over time :) What about you other guys?

I can get over it, but I think we employ other practices that can lead to
more serious bugs.  Complex ternary expressions, assignment to method
parameters, assignment to catch block parameters, use of nested postfix
operators, etc.  But that's drawn from my own experience as well.

Let me start using "final" and I'll give up on autoboxing ;-)

-- 
Kevin


Re: svn commit: r605850 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/ apache/cayenne: ./ access/ access/jdbc/ access/types/ dba/ dba/openbase/ dba/oracle/ dba/sqlite/ dba/sqlserver/ exp/parser/ query/ reflect/ util/ wocompat/

Posted by Tore Halset <ha...@pvv.ntnu.no>.
On Dec 20, 2007, at 14:35 , Kevin Menard wrote:

> On 12/20/07 7:06 AM, "Tore Halset" <ha...@pvv.ntnu.no> wrote:
>
>>
>> I am currently -1 to autoboxing, but Integer.valueOf(int) should not
>> be a problem for anyone.
>
> Why is that?  I was just about to commit changes that replaces all  
> of the
> explicit unboxing and boxing code with autoboxing.  This would  
> improve code
> clarity in various places.

It will make the code smaller, but will the code be clearer? As in  
easier to understand?

> Autoboxing yields nearly identical bytecode to manual boxing/unboxing
> operations.  The only time I've found it's problematic is when you  
> forget
> what type you're working with to the point that you really should be  
> using
> the object type or the primitive type natively.

I have been bitten by a couple of situations where I thought my  
primitive type was primitive, but in fact had been autoboxed. This is  
extra confusing when you have objects that have identical methods, but  
with primitive and non primitive arguments. Like  
List<Integer>.remove(int) and List<Integer>.remove(Integer) doing two  
very different things. It is also a bit confusing when autoboxing  
happens when you do not know about it. I do not have that many good  
examples, but have googled some discussion around the subject.

http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/867001348831/r/448008648831
http://www.theserverside.com/news/thread.tss?thread_id=27129

Perhaps I can learn to like it over time :) What about you other guys?

- Tore.


Re: svn commit: r605850 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/ apache/cayenne: ./ access/ access/jdbc/ access/types/ dba/ dba/openbase/ dba/oracle/ dba/sqlite/ dba/sqlserver/ exp/parser/ query/ reflect/ util/ wocompat/

Posted by Kevin Menard <km...@servprise.com>.
On 12/20/07 7:06 AM, "Tore Halset" <ha...@pvv.ntnu.no> wrote:

> 
> I am currently -1 to autoboxing, but Integer.valueOf(int) should not
> be a problem for anyone.

Why is that?  I was just about to commit changes that replaces all of the
explicit unboxing and boxing code with autoboxing.  This would improve code
clarity in various places.

Autoboxing yields nearly identical bytecode to manual boxing/unboxing
operations.  The only time I've found it's problematic is when you forget
what type you're working with to the point that you really should be using
the object type or the primitive type natively.

-- 
Kevin


Re: svn commit: r605850 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne: ./ access/ access/jdbc/ access/types/ dba/ dba/openbase/ dba/oracle/ dba/sqlite/ dba/sqlserver/ exp/parser/ query/ reflect/ util/ wocompat/

Posted by Tore Halset <ha...@pvv.ntnu.no>.
Hello.

(sorry if this show up several times. looks like I have some unstable  
mail today..)

On Dec 20, 2007, at 10:47 , Aristedes Maniatis wrote:

> On 20/12/2007, at 8:44 PM, torehalset@apache.org wrote:
>
>> java 5: new Integer(int) -> Integer.valueOf(int)
>
> Or we could start to use autoboxing and just use "int" where  
> appropriate. Is valueOf recommended over new Integer() for speed or  
> other reasons in Java 5?


I am currently -1 to autoboxing, but Integer.valueOf(int) should not  
be a problem for anyone.

 From javadoc:
"Returns a Integer instance representing the specified int value. If a  
new Integer instance is not required, this method should generally be  
used in preference to the constructor Integer(int), as this method is  
likely to yield significantly better space and time performance by  
caching frequently requested values."

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Integer.html#valueOf(int)

Regards,
- Tore.

Re: svn commit: r605850 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src/main/java/org/apache/cayenne: ./ access/ access/jdbc/ access/types/ dba/ dba/openbase/ dba/oracle/ dba/sqlite/ dba/sqlserver/ exp/parser/ query/ reflect/ util/ wocompat/

Posted by Craig L Russell <Cr...@Sun.COM>.
I didn't see a reply to this one.

On Dec 20, 2007, at 1:47 AM, Aristedes Maniatis wrote:

>
> On 20/12/2007, at 8:44 PM, torehalset@apache.org wrote:
>
>> java 5: new Integer(int) -> Integer.valueOf(int)
>
> Or we could start to use autoboxing and just use "int" where  
> appropriate. Is valueOf recommended over new Integer() for speed or  
> other reasons in Java 5?

Yes, it's recommended. The valueOf method returns an instance that  
might already be lying around whereas new Integer will always create  
an object that will have to be garbage collected later. So valueOf is  
preferable if the code will always be run in a Java 5 or better vm.

Craig
>
> Ari
>
>
>
> -------------------------->
> Aristedes Maniatis
> phone +61 2 9660 9700
> PGP fingerprint 08 57 20 4B 80 69 59 E2  A9 BF 2D 48 C2 20 0C C8
>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!