• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Using == operator on wrapper classes

 
Ranch Hand
Posts: 658
2
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Roel De Nijs wrote:Because every integral literal in Java is by default an int. Just like any decimal point literal is by default a double.


I was aware of this, read it in K&B book, but in confusion that why not a suffix (like f, l, L) is used in short as integral type are by default int
 
Ranch Hand
Posts: 789
Python C++ Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Puspender Tanwar wrote:

Roel De Nijs wrote:Because every integral literal in Java is by default an int. Just like any decimal point literal is by default a double.


I was aware of this, read it in K&B book, but in confusion that why not a suffix (like f, l, L) is used in short as integral type are by default int



I think it is just incredibly annoyingly arbitrary. There are a few of those things.
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Puspender Tanwar wrote:but in confusion that why not a suffix (like f, l, L) is used in short as integral type are by default int


Because it's not defined in the IntegerTypeSuffix The next post explains why the existence of the L (or l) suffix is required, so just keep reading
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Guillermo Ishi wrote:I think it is just incredibly annoyingly arbitrary. There are a few of those things.


For the integral types, it's only for long. And that makes sense, because each integer literal is an int. So if you have a literal which is outside the range of an int, you need an indicator to tell the compiler it should be handled as a long and not an int; otherwise you'll end up with a compiler error. This code won't compile without the L (or l) suffixThat means the L (or l) suffix is not optional but required to use if you are working with a long literal.

And because a short is smaller than an int, you can always use casting to make the compiler treat it as a short (and not an int) like in this code snippetBut this doesn't work for a long literal, because a long is outside the int range as this code snippet illustratesThe only way to fix it, is to use the L (or l) suffix

Hope it helps!
Kind regards,
Roel
 
Ranch Hand
Posts: 388
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I knew I'd come back to this post eventually

Such a good post about boxing on the first page Roel, so I thought I'd bump this, rather than start a new thread.

anyway, for example 12, you said:


System.out.println(myInt1 == myNumber1); // 12 compilation fails incompatible operand types int and Number. !!!

This statement is again a little tricky, but indeed does not compile. You may think the Java compiler will simply unbox this value as well (like with the other statements). But although Number is the (abstract) parent class of concrete classes Integer, Long, Float,... boxing/unboxing does not work with Number. The Java compiler needs to know exactly what type of number it's dealing with to perform the boxing/unboxing.



but in question 17 you mention:


System.out.println(myInteger1 == myNumber1); // 17 true

Let's have a look at this tricky statement. It prints indeed true. But why? First of all, this code compiles successfully. No compiler error like with line16 and line18. So no incompatible types here, because these types are not different from each other. Integer IS-A Number. Now let's look at line6: Number myNumber1 = 10;. We already know this 10 is an int and thus the compiler will wrap/autobox it into an Integer using Integer.valueOf(10) resulting in this statement: Number myNumber1 = Integer.valueOf(10);



I understand most of the topic of unboxing and boxing now I think, but this confused me slightly.

I'm guessing that the difference between these two is that the second is actually compiling because of the IS-A relationship and is not even attempting unboxing at all?
so the second statement is true not because the values are both 10, but because myNumber and myInteger both point to the cached object 10?

thanks,

Nick

* edit: on reading your explanation again, that's pretty much what you said I just took your second explanation slightly out of context. Still there is *something* that I can't quite put my finger on that I think is eluding me. Maybe that unboxing never occurs with '==' and two wrappers? Does that sound like a good rule to follow?
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

nick woodward wrote:Such a good post about boxing on the first page Roel, so I thought I'd bump this, rather than start a new thread.


Maybe I should convert this topic into a very, very, very tiny book about (auto)boxing, remove this topic from the forum and sell that book on Amazon for big bucks You are referring to examples used in this thread, so in this case a follow-up post is better than starting a new topic

nick woodward wrote:I'm guessing that the difference between these two is that the second is actually compiling because of the IS-A relationship and is not even attempting unboxing at all?
so the second statement is true not because the values are both 10, but because myNumber and myInteger both point to the cached object 10?


Your guess is absolutely spot-on!

In example12 we are comparing a primitive variable (myInt1) and a wrapper class reference variable (myNumber1). And you have passed the OCAJP7 certification exam, so you know: when == is used to compare a primitive to a wrapper, the wrapper will be unwrapped and the comparison will be primitive to primitive. In order to unwrap (unbox) the wrapper, the Java compiler needs to know exactly what type of number it's dealing with. Because the type of myNumber1 is Number, the Java compiler doesn't know the type and therefore compilation fails.

Now let's look at example17: at first glance it might look very similar to example12, but there is one very important difference. In example17 we are comparing the wrapper class reference variables myInteger1 and myNumber1. If you compare two reference variables, no unwrapping (unboxing) will happen at all! So the == operator checks if both reference variables refer to the same object and if they do return true (and false otherwise). Because both myInteger1 and myNumber1 refer to the (cached) Integer object with value 10, that statement will print true.

Hope it helps!
Kind regards,
Roel
 
nick woodward
Ranch Hand
Posts: 388
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
it does help, thanks!

oh, and if you're going to be writing multiple books, however small, I'll lower my cut to 15%
 
snakes are really good at eating slugs. And you wouldn't think it, but so are tiny ads:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic