About Question enthuware.ocajp.i.v7.2.1392 :

Help and support on OCA OCP Java Programmer Certification Questions
1Z0-808, 1Z0-809, 1Z0-815, 1Z0-816, 1Z0-817

Moderator: admin

scranen
Posts: 12
Joined: Thu May 07, 2015 8:55 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by scranen »

Sure, but at runtime, if the left argument s of type String turns out to be null, then s instanceof String does not hold. For all intents and purposes, therefore, s is not a string at that point (regardless of what the type checker decided at compile time). So for the following code snippet,

Code: Select all

String s = null;
s = s + 'c';
the compiler decides at compile time that it is will be concatenating a character 'c' to a string s. Runtime, however, it has to decide how to deal with the fact that s is not a String (it is, in fact, null, which is of the (unnamed) null type). The Oracle Java compiler decides to convert s to the String object with value "null" to overcome this issue. The JLS however does not require that this conversion be done, it only says that 'c' should be converted to a String -- more to the point, it does not prescribe what the semantics of concatenating a null value and a string of characters is.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by admin »

OK, it looks like your whole argument is based on the fact that since the instanceof check returns false at runtime, it is not a String and so the operation is not defined by JLS.

My point is the symantics of instanceof clearly require that the left operand must not be null for it to return true. But null can actually be cast to any type. For example, the following runs fine even though a instanceof String (or even Object) is false:
Object a = null;
String s = (String) a;

This means a is-a String.

My question is, why do you insist on the result of instanceof test and not on the cast test?
If you like our products and services, please help us by posting your review here.

scranen
Posts: 12
Joined: Thu May 07, 2015 8:55 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by scranen »

I'm using the instanceof test to illustrate that it is not reasonable to say that null can semantically be seen as a string (note that I am using "string" (with lowercase s) to refer to the semantic notion of a string of characters; I do not argue that null cannot be argued to be of type String). I will rephrase my argument to not use this test.

Maybe my point becomes clearer if I explain how I interpret the JLS on string concatenation. Given that s+o is an expression in which the reference variable s is of type String, and the reference variable o is of type Object, the only thing we know about these variables is that during run time, they will contain a reference to a String and a reference to an Object. I completely agree with you that there is nothing wrong with the typing, even if s turns out to be a null reference, its type is still String.

If I now ask myself what the JLS says about the result of the expression, I have to interpret what "the concatenation of the two operand strings" means (this is what the JLS says is the return value). The only way in which I can interpret this is that it means in the case of s+o is "the concatenation of the two strings referenced by s and o". Two problems can occur:
  1. o references an object that is not a string. In that case, the expression o was not of type String, so this case is covered by the specification: it says to convert the object to a string first.
  2. o or s does not reference any object at all (i.e., is a null reference). In this case, the JLS does not say what happens, because we don't have two strings to concatenate. We have two expressions of type String, but semantically, at least one of them does not actually represent a string. The Java compiler decides in this case to interpret the null references as a reference to the string "null", but this is not prescribed by the JLS.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by admin »

OK, I got your point.
thank you for your patience :)
If you like our products and services, please help us by posting your review here.

scranen
Posts: 12
Joined: Thu May 07, 2015 8:55 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by scranen »

Haha np. It gets even more confusing because the conversion for o to "null" in case of a null reference may actually be quite reasonable, as "string conversion is performed" on o anyway. This depends on what "string conversion" means, and whether it is an operation on objects or on object references -- I don't think JLS says anything about this.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by admin »

JLS does describe string conversion in Section 5.1.11.
If you like our products and services, please help us by posting your review here.

scranen
Posts: 12
Joined: Thu May 07, 2015 8:55 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by scranen »

Oops :oops: Thanks for the reference.

pbonito
Posts: 13
Joined: Sat May 16, 2015 12:38 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by pbonito »

I think it is strange that two variables so defined String a = null , String b ="null" can have similar behaviour in operations such concatenation and print, but totally and correctly different in others (trim ,concat ecc. ecc.)

It's just a rule or I can understand it someway.

Thanks

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by admin »

null and "null" are two entirely different things. The output that you see with null is because it is treated differently by the print (and concatenation) method but nothing surprising about "null".
You just need to remember it.
If you like our products and services, please help us by posting your review here.

Agoosen
Posts: 2
Joined: Fri Jun 26, 2015 4:37 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by Agoosen »

The answer to the question, first line, reads:

Since newStr is null at the beginning, the first iteration of the loop assigns "nullg" to newStr.

In my opinion, the correct explanation is:

"The statement in the loop uses the '+' operator to concatenate two objects. The first object is a String, it therefore (by design) uses the valueOf() method of the String Class. The API for this method says that if it is called with a null reference (*which it is* in our case), the method returns the string "null". "

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by admin »

Actually, the given explanation is correct but it skipped the details that you've mentioned. These details are covered in other questions.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

Jokumo♫
Posts: 6
Joined: Wed Apr 20, 2016 9:56 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by Jokumo♫ »

admin wrote:Actually, the given explanation is correct but it skipped the details that you've mentioned. These details are covered in other questions.
The explanation indeed is correct somehow, but without the details of Agoosen it sounds like null == "null". In my opinion it would help a lot to include those details in the explanation.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by admin »

The details provided in the previous post by Agoosen are not correct. JLS Section 15.18.1 doesn't say anything about using valueOf. In fact, in section 15.1.11 mentions that toString() is used to convert a non-string operand to a String value.

So, if your String operand is null, the + operator treats it pretty much as "null". Thus, null + 'g' will be evaluated as "nullg" as given in the explanation.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

Jokumo♫
Posts: 6
Joined: Wed Apr 20, 2016 9:56 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by Jokumo♫ »

damn, you're right (as always)

now I see it in JLS Section 5.1.11 about String converion
If the reference is null, it is converted to the string "null" (four ASCII characters n, u, l, l).
thanks a lot. Much easier to accept it that way

Chanandler
Posts: 1
Joined: Thu Aug 25, 2016 1:33 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by Chanandler »

Did something go wrong here?

Look for correct/green answer and the explanation:
and true for newStr.equals(myStr)
Attachments
Zrzut ekranu 2016-08-25 o 20.34.12.png
Zrzut ekranu 2016-08-25 o 20.34.12.png (34.13 KiB) Viewed 11019 times

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by admin »

Please read the explanation carefully. It is correct. It is talking about a different case. Had newStre been defined as String newStre = ""...
If you like our products and services, please help us by posting your review here.

vandreev
Posts: 1
Joined: Mon Jul 02, 2018 10:36 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by vandreev »

all the chars will be concatenated to null, so newStr = nullgood in the end

st.lisker
Posts: 22
Joined: Sat Jun 30, 2018 6:11 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by st.lisker »

String myStr = "good";
char[] myCharArr = {'g', 'o', 'o', 'd' };

System.out.println(myStr == "good");

String newStr = "";
for(char ch : myCharArr){
newStr = newStr + ch;
}

System.out.println("_____________________________");
System.out.println(newStr.hashCode()); //3178685
System.out.println(myStr.hashCode()); //3178685
System.out.println(newStr==myStr); // false -------------> But why?

The explanation says that these are two different objects, but why? There was not new(). They are put in the pool. They even have the same hash code. Why the false?

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by admin »

Just because the hashCodes of two objects are equal doesn't mean that the objects themselves are equal. (There reverse is actually true i.e. if the objects are equal then the hashCodes will be equal).
A String created using concatenation where its operands are not compile time constants is a new String.
If you like our products and services, please help us by posting your review here.

st.lisker
Posts: 22
Joined: Sat Jun 30, 2018 6:11 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by st.lisker »

Thanks for the answer!
"Just because the hashCodes of two objects are equal doesn't mean that the objects themselves are equal." -> I thought, it means that they are the same object 8-(
"A String created using concatenation where its operands are not compile time constants is a new String" -> OK, got it (This point can be on the exam? )

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by admin »

>This point can be on the exam?
Yes, it is possible but most probably not.
If you like our products and services, please help us by posting your review here.

rali14043
Posts: 2
Joined: Sat Jan 19, 2019 4:38 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by rali14043 »

This is a bug in Java since If I write the following line they don't compile:

String newStr = null (compiles successfully)
String newStr1 = Null (does not compiles)
String newStr2 = NULL (does not compiles)
String newStr3 = abcd (does not compiles)

I don't understand while String newStr = null compiles while any other values don't compile.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by admin »

Java is case sensitive. null is a keyword but Null and NULL are not. Neither is abcd. So, the compiler thinks that Null, NULL, and abcd are variable names.

Also, pay close attention to the error message. It will tell you exactly what the compiler is thinking.

Are you following any book?
If you like our products and services, please help us by posting your review here.

itvase
Posts: 1
Joined: Tue Jan 09, 2024 10:52 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by itvase »

Chanandler wrote:
Thu Aug 25, 2016 1:36 pm
Did something go wrong here?

Look for correct/green answer and the explanation:
and true for newStr.equals(myStr)
I have the same concern as you.
It's strange that admin hasn't responded to this for more than 7 years.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1392 :

Post by admin »

itvase wrote:
Thu Jan 11, 2024 11:50 pm
Chanandler wrote:
Thu Aug 25, 2016 1:36 pm
Did something go wrong here?

Look for correct/green answer and the explanation:
and true for newStr.equals(myStr)
I have the same concern as you.
It's strange that admin hasn't responded to this for more than 7 years.
The reply to this query is there at the top of this page.
I am not sure what is the issue.
If you like our products and services, please help us by posting your review here.

Post Reply

Who is online

Users browsing this forum: No registered users and 50 guests