Enthuware

Short k = new Short(9); System.out.println(k instanceof Short);
9 is considered an int. This should be: Short s = new Short( (short) 9 );

Why 9 is considered an int?

Any integer literal (i.e. any hardcoded number without decimal) is always assumed to be an int.

When you assign it to a short variable, an implicit narrowing coversion happens that converts it into a short (only if the literal is small enough to fit into target type). So,
short s = 9; //this is ok because even though 9 is an int, an implicit narrowing conversion makes it a short because the value 9 is small enough to fit into a short.
short s = 999999999; //this is not ok because the number is too large to be stored in a short so implicit narrowing cannot happen.

Further, implicit narrowing never happens (whether the number is small or large) when it is passed in a method or constructor.

So, in case of new Short(9); 9 is an int and remains an int and that is why it does not compile.

HTH,
Paul.

Will this Integer i=9; be unboxed and then compared according to the last option?

Deepa wrote:Will this Integer i=9; be unboxed and then compared according to the last option?

Yes, in this option, i is a wrapper object and s is a primitive so i will be unboxed and then the values will be compared.

If both are wrappers, then no unboxing will happen. They will be compared by their references (instead of the value that they contain).

HTH,
Paul.

For the last option, does the auto-unboxing of Integer i occur before the evaluation? I think it does so that it can compare with s, right?

Right.

You stated that implicit narrowing never occurs when passed to a method or constructor. I am not doubting you but where do you get all of these information. I have a couple of books and I don't recall any of them ever mentioning these. I need to find out what/where is the source I will not miss these types of questions.

BTW.. this is more of an aside. I have taken two of your standard test and have not encountered questions regarding try-with-resource.

The source for all this information is The Java Language Specification
Try with resource is not required for the OCAJP exam.

admin wrote:Any integer literal (i.e. any hardcoded number without decimal) is always assumed to be an int.

When you assign it to a short variable, an implicit narrowing coversion happens that converts it into a short (only if the literal is small enough to fit into target type). So,
short s = 9; //this is ok because even though 9 is an int, an implicit narrowing conversion makes it a short because the value 9 is small enough to fit into a short.
short s = 999999999; //this is not ok because the number is too large to be stored in a short so implicit narrowing cannot happen.

Further, implicit narrowing never happens (whether the number is small or large) when it is passed in a method or constructor.

So, in case of new Short(9); 9 is an int and remains an int and that is why it does not compile.

HTH,
Paul.

So we says that
"implicit narrowing never happens (whether the number is small or large) when it is passed in a method or constructor."
And there for in
Short k = new Short(9);
"9 is an int and remains an int and that is why it does not compile."

So why would
Long m = new Long(9)
compile?
Shouldn't we have the same problem here?

9 is promoted to long. This is implicit widening. Not narrowing.

So is it correct to assume that:
1. implicit narrowing never happens (whether the number is small or large) when it is passed in a method or constructor.
2. implicit widening does happens even when it is passed in a method or constructor.
?

Yes, that is correct.

When we have Isn't s a primitive of type short and i and Object Integer?
Then why would the == work?
Shouldn't == fail to compile, because the two sides of == are two totally different entities?

This works because of auto-unboxing of Integer to int. This is not in scope for this exam though.

How come Integer i=9 can be compared to short s, but not Short k?

Because short s is a primitive and Integer i will be unboxed for comparison (so both i and s will be numeric primitives) while Short s is an Object. Objects references of different classes (i.e. classes which have no relationship) cannot be compared.

I think the "easy" is debatable. To answer this question correctly you do have to have some detailed knowledge that I actually never needed. I have been using Java for many years and scored 91% on this test but I had this question wrong. Well, no problem actually, that is part of the charm of going for certification. It makes me learn some new details every day.

Anyway, most people will use int by default so Short's aren't that common. The knowledge I was missing was that
- Short does not have a constructor taking an int
When you think about it this actually does make sense because an int can be out of range. Still the API could have been designed to have such a constructor and let it throw an exception for out-of-range values.

- comparing a primitive to a wrapper type will UNbox the wrapper type instead of BOXing the primitive, so a short can be compared to an Integer.
Ok shame on me I should have known this one! Or at least I could have inferred that this is much more logical than boxing the primitive because this could result in the comparison returning false while the numbers are actually equal.

This still makes me wonder if the question should have been labelled "easy"...

you said:
Short is a primitive.

Short is a primitive type, but Short is considered all primitive type?

Thanks Paul

Not sure where did I say that Short is a primitive but anyway - short with small s is a primitive. Short with capital S is an object.
Paul.

Assigning a double value to a primitive float results in compiler error: possible lossy conversion from double to float.

On the other hand the creation of a Float instance is working well with a double. This is tricky, but there is a third constructor accepting double value.

Short lng = new Short(9); // error
Long lng1 = new Long(10);// ok
Double dbl = new Double(20);// ok
Float fl = new Float(10);// ok
Byte b1 = new Byte(20);// error

How is it possible to remember all this constructors???

There are not that many. All of these wrapper classes have only two constructors - one that takes a primitive and one that takes String. For example, Byte has Byte(byte ) and Byte(String ), Integer has Integer(int) and Integer(String ). The only exceptional case that you need to remember is that Float has a third constructor that takes a double as well.

Now, just remember the reasoning behind what is supported and what is not. The number 9 is an integer literal. If you try to pass an integer literal to a Byte, Char, or Short, it will not compile because of possible loss of information (since an int is bigger in size than byte, char, or short).
So new Short(9) or new Character(9) or new Byte(9) will not compile.

An int is smaller than a long, so new Long(10) or new Float(10) or new Double(20) will work fine.

Hm, thanks, good explanation.

In this question it is given that:
short s = 9;
In option 4 it is given:
int i = 9; System.out.println(s == i);
In the explanation it is written that any two integral primitives can be compared by using == operator.
As per my java knowledge, integral primitives are byte, short, int and long. Floating point primitives are float and double.
But what I found out that we can still compare an int with a float or a double by using "==" operator.
int i = 9;
float f = 9.0f;
System.out.println(i == f); //Output is true.
Can you please clarify whether we can apply the "==" operator only for integral primitive data types or for all numerical primitive data types.
Regards
Raj

The explanation that you are referring to is attached to that particular option. It is In that context that it says that two integral primitives can be compared using == because this option tries to compare two integral primitives (short and int).

But yes, in general, you can compare any two numerical values/variables using ==. However, that still doesn't mean you can't compare primitive value and a primitive wrapper (such as int and Integer or int and Float) using ==. You can. The point is, there are several rules and you will need to go through a book to learn all the rule because all the rules cannot be specified in an explanation to an option.

But if you go through all the questions and their explanations in our question bank, all the rules will be covered.