Dean Nillson

Scott Selikoff wrote:Special things happen with the compound assignment operators, such as +=, if you keep reading!

indeed... the authors of Java like to keep us on our toes :-)

alright... never mind... the next page mentions that unary operators are excluded from the third rule. Sorry about that.

Hi all,

I am going through the chapter 2 (operators) of Jeanne and Scott's book on OCP 17 and I have a question about the numeric promotion rule number 3: "Smaller data types, namely, byte, short, and char, are first promoted to int any time they're used with Java binary arithmetic operator with a variable (as opposed to a value), even if neither of the operands is int."

From this rule, I would expect the following code to fail to compile but it does not:

short x = 8; short result = ++x;

The second statement includes an arithmetic operator and a variable, I would expect x to be promoted to an int and the result assigned to the variable result to be an int. In which case assigning an int into a short should raise a compilation error.

What am I misunderstanding or missing?

Thanks for the advice Jeanne and thanks for the great study guides.

Thanks a lot Paul.

Hi everyone,

Do you have any recommendations on where to find practice exams for the OCP 17 certification? I saw that Scott and Jeanne's practice tests book won't be released until Sept 2022. I would like to take the exam earlier than that.
Any word on when Enthuware would release their practice tests?

Paul Clapham wrote:Here's what the Java 1.0 JLS says about that topic: http://titanium.cs.berkeley.edu/doc/java-langspec-1.0/5.doc.html#170768

I invite you to compare the two and see if there are any differences. I wouldn't think there were, since language features related to primitives haven't changed at all as far as I know. There's boxing and unboxing, and there's parameter typing, but I don't believe any of those should affect how primitives work. The Java designers are quite careful about forward compatibility between versions.

Thank you Paul. I guess my memory is failing me. It has been this way indeed.

Thanks again!

Tony Docherty wrote:
Or put simply the compiler can auto downcast the expression if it is a constant of type byte, short, char, or int and it is being assigned to a variable of type byte, short, or char and it will fit into that variable. ie 127 can be assigned to a variable of type byte but 1024 can't be.

Do you know in which version of Java this automatic casting was added? I was expecting to have to cast the literal to short.

Thanks a lot guys. I appreciate your input.

Srini Jayaraman wrote:

Can you suggest for the error on line 27  if possible. Thanks again

Srini,

I ran your code and I don't have any error on line 27.

Here is the output of your code:

[puddle, quack]
[quack, puddle]

Line 17, you forgot the type at the instantiation of the comparator.

new Comparator<> becomes new Comparator<Duck>

Hi Yossuf,

It’s not as much about how neat it looks but how readable it is to another programmer.

It’s advised to keep the method signature on one line and the body of the method indented.

As I am sure you have seen, Indentation and carriage returns help a lot to identify right away a specific block of code.

I understand it might not seem crucial on your example of just a return statement but when I see a tight portion of code like your first example, I think more of variables declaration rather than methods definitions.

Hi Mike,

Could you post the code causing the error.

Thanks
D.

Duc Ta wrote:
I know it, but if I never enter into the loop it mean that the method variables i and j is never initialized. It mean that there will compile error because the value of method variables must be initialized before they are used, but there is no error the code compile normally. This is my confusing part.

What I mean by it will not enter the loop is that it will not enter the loop block.
Before the first iteration, the variables are still initialized and the control condition evaluated.

you never enter into the loop.

the condition of your loop is j < i (0 < 0), it returns false right away.

The output that you see is from the the System.out after the loop.

D.