Oracle Certified Professional Java SE 7 Programmer Exams 1Z0-804 and 1Z0-805 by Ganesh/Sharma

[Nancy Avent]

Alexander Weickmann wrote:Mock Test - 1 Question 83. seems to be wrong. It's OK to define a finally block when using try-with-resources but the book says this is not allowed.

It's interesting. The book says finally block is not "applicable" (and not "not allowed") with try-with-resources. I think, it makes sense.

[Alexander Weickmann]

I don't see how it would make sense ... there might be clean-up work to do other than closing the resources. E.g. closing stuff that does not implement AutoCloseable, resetting static variables, implementation-specific stuff like WatchKey.reset() ...

[Alexander Weickmann]

The exam topics state:
"Format strings using the formatting parameters: %b, %c, %d, %f, and %s in format strings"

But in the mock exams the authors heavily use other stuff as well. For example: %t<B

I think it's fine if they want to toughen us up, but I don't think it's efficient to learn stuff that is not on the exam ...

[S G Ganesh]

** Errors fixed in the latest update of the book. **

Myself and Tushar - authors of OCPJP 7 book which is discussed in this thread - took up the task of writing the book in an incredibly tight schedule. As I mentioned earlier in one of the mail chains in this group, we wanted the book to be out as soon as the beta exam becomes the final exam, and we missed that deadline only by a month or so. Given the fact that both of us (Tushar and myself) have a full-time demanding job, hyperactive kids in our respective homes, and short deadlines, we're extremely happy that our book came out to the market as the first book on OCPJP 7 exam preparation.

With the tight schedule, we couldn't get much time for reviews and rigorous checks, and quite a few mistakes slipped into the production version of the book - that is the major criticism of our book. We are thankful to our readers who were supportive of us as well as reported bugs. Now, all the known mistakes are fixed in the book and the updated version is available in ebook form and Print-On-Demand books; for the print version, for the further reprints, this updated version will be available. Note that the book in its current form is quite comprehensive, covers almost all topics in required depth, and uses an example-driven approach which makes the concepts easier to understand. Given the fact that this is the only book (to our knowledge) to *prepare* for OCPJP 7 exam available in the market, we hope that this updated version is very helpful to our readers.

Our hearty thanks to the all the readers who were patient with us and helped us by reporting the errors in the errata page for the book. I've copied the image from the book acknowledgement section of the book (if we have missed anyone in this list, we are sorry for that and please do let us know).

Cheers,
Ganesh & Tushar

[Alex Benedict]

Finally, I passed the OCPJP 7 exam.
Thanks to the authors of this book that made it possible.

Also, it is nice to hear that the new version of the book available with errata addressed. Best of luck to authors of the book.

[Des Robin]

Didnt see this error anywhere else:

Page 541, Mock test 1, question 65.

The answer to this question is 'a'. However the reason stated is the use of 'transient'. This is not the case. If transient is removed, the code still works as the static variable 'term' retains its value as the class has already been loaded when the program deserializes the object. If the code to deserialize is split into its own program (i.e. forcing the class to be reloaded when you run the second program), the return value becomes 'b' because the class is loaded for the first time and as static variables are not serialized, the value is lost.

[Tyson Lindner]

To authors:

Do you think you could create a sorted list of errata from the first print edition? It would be much easier to correct. Also some of the posts on the errata message board weren't addressed so I'm not sure if they're correct or not.

[T. Sharma]

Tyson Lindner wrote:To authors:

Do you think you could create a sorted list of errata from the first print edition? It would be much easier to correct. Also some of the posts on the errata message board weren't addressed so I'm not sure if they're correct or not.

We maintain an errata page for the book where all the known mistakes are presented in a sorted manner. Anybody can download the errata document.

We recently fixed the mistakes (known till that point) and now Amazon and other sites are offering the new version of the book. After this fix, on our errata page, we are currently maintaining all the mistakes that are not fixed yet (i.e. not fixed in first revision). I think, Tyson is referring to old errata list that should also be available along with the new errata list. I agree to this, and in a couple of days, we will make that available too.

Some of the mistakes, that are reported by readers, are not appearing into the errata document because we have not validated them whether they are really mistakes. We do it periodically; therefore, we will update the errata document with the unprocessed instances very soon.

I hope, this answers Tyson's query.

[Devaney Marcondes]

Devaney Marcondes wrote:In my opinion the question 5 of the chapter 7 have 2 correct answer.
The B and C are correct.

I will correct myself but the book answer is still incorrect.
The correct answer is C.
The book explanation say:

Answer: B. “b\ D\ w*@\ w +\. com\ b” (“\ b” is used to mark word boundaries,
“\ D” is used to match any non-digit number, and “\ w*”
is used to match any word of length zero or more.
The remaining part is similar to that used earlier.)

For this reason \w* is wrong because if the email is "@notaemail.com" the regex “b\ D\ w*@\ w+\. com\ b” will accept it.
The right regex is “b\ D\w+@\ w +\. com\ b” (with the plus before @).

------
On the page 207 have a typing error:
instead "In matchStr, check for matchLen characters starting from matchStartOffset."
must be instead: "In matchingStr, check for matchLen characters starting from matchStartOffset."

[T. Sharma]

Devaney Marcondes wrote:

I will correct myself but the book answer is still incorrect.
The correct answer is C.
The book explanation say:

Answer: B. “b\ D\ w*@\ w +\. com\ b” (“\ b” is used to mark word boundaries,
“\ D” is used to match any non-digit number, and “\ w*”
is used to match any word of length zero or more.
The remaining part is similar to that used earlier.)

For this reason \w* is wrong because if the email is "@notaemail.com" the regex “b\ D\ w*@\ w+\. com\ b” will accept it.
The right regex is “b\ D\w+@\ w +\. com\ b” (with the plus before @).

Dear Devanev, with due respect I think your explanation is not correct. You are missing "\D" which is used in this question to satisfy the requirement of the question that the email address must not start with a digit. Thus, the regex will not match to "@notaemail.com" because the regex looks for a not digit (due to "\D") which is missing. Since, "\D" is already used, there should be "\w*" (and not "\w+") to make the expression correct; otherwise it will not match to addresses like "[email protected]". I hope it will help.

You are right about the typo, we will include that in our errata doc. Thanks for that.

[Devaney Marcondes]

T. Sharma wrote:

Devaney Marcondes wrote:

I will correct myself but the book answer is still incorrect.
The correct answer is C.
The book explanation say:

Answer: B. “b\ D\ w*@\ w +\. com\ b” (“\ b” is used to mark word boundaries,
“\ D” is used to match any non-digit number, and “\ w*”
is used to match any word of length zero or more.
The remaining part is similar to that used earlier.)

For this reason \w* is wrong because if the email is "@notaemail.com" the regex “b\ D\ w*@\ w+\. com\ b” will accept it.
The right regex is “b\ D\w+@\ w +\. com\ b” (with the plus before @).

Dear Devanev, with due respect I think your explanation is not correct. You are missing "\D" which is used in this question to satisfy the requirement of the question that the email address must not start with a digit. Thus, the regex will not match to "@notaemail.com" because the regex looks for a not digit (due to "\D") which is missing. Since, "\D" is already used, there should be "\w*" (and not "\w+") to make the expression correct; otherwise it will not match to addresses like "[email protected]". I hope it will help.

You are right about the typo, we will include that in our errata doc. Thanks for that.

Thanks a lot for your answer.
You're right about to not use "\w+", whatever, the answer B is wrong too.
Try to execute the code below:

import java.util.regex.Matcher;
import java.util.regex.Pattern;
class SearchEmail{

 public static void main (String[] args){

	System.out.println("Now we will try with w* (like answer B)");
	String str = "My email is hear [e-mail], and nor " +
		"a@12345com " +
		"neither myemail@itIsNotAMail!com " +
		"neither @itIsNotAMail.com" + 
		"neither [e-mail]" + 
		" is my email.";
	String regex = "\\b\\D\\w*@\\w+\\.com\\b";

	Pattern pattern = Pattern.compile(regex);
	Matcher matcher = pattern.matcher(str);
	
	while(matcher.find())
		System.out.println(matcher.group());

	System.out.println("Now we will try with w+ (like answer C)");

	regex = "\\b\\D\\w+@\\w+\\.com\\b";

	pattern = Pattern.compile(regex);
	matcher = pattern.matcher(str);
	
	while(matcher.find())
		System.out.println(matcher.group());

 }
}

Thanks.

[T. Sharma]

Thanks Devaney. However, I still have a point

When we execute the code provided by you, I got the following result:

Now we will try with w* (like answer B)
 [e-mail]
 [e-mail]
Now we will try with w+ (like answer C)
 [e-mail]
 [e-mail]

When we see the output, it looks like that option B is not correct. However, a more closer look reveals that the matched string is " [email protected]" i.e. a string starting from a white-space. Because of this white-space, the string is matched to our regex. To make sure whether the regex in option B will match to correct email address, I tried the following code:

import java.util.regex.Matcher;
import java.util.regex.Pattern;
 
 class Regex1 {
        public static void main(String[] args) {
                String str = "[e-mail]";
                Pattern pattern = Pattern.compile("\\b\\D\\w*@\\w+\\.com\\b");
                Matcher matcher = pattern.matcher(str);
                while(matcher.find()) {
                        System.out.println(matcher.group());
                }
        }
}

The code snippet does not print anything that suggests that option B is the correct answer.

[Devaney Marcondes]

Hi.
In this case the regex "\b\D\w+@\w+\.com\b" will fine too, because it don't print anything.

Look:

import java.util.regex.Matcher;   
import java.util.regex.Pattern;   
    
class Regex1 {   
 public static void main(String[] args) {
		
	//With space
	String str = " [e-mail]";
	String regex = "\\b\\D\\w*@\\w+\\.com\\b";
	printEmail(str, regex);

	regex = "\\b\\D\\w+@\\w+\\.com\\b";
	printEmail(str, regex);

	//Without space
	str = "[e-mail]";
	regex = "\\b\\D\\w*@\\w+\\.com\\b";
	printEmail(str, regex);

	regex = "\\b\\D\\w+@\\w+\\.com\\b";
	printEmail(str, regex);

 }

 static void printEmail(String str, String regex){
	System.out.println("Try to find " + str + " with regex " + regex);
	Pattern pattern = Pattern.compile(regex);   
	Matcher matcher = pattern.matcher(str);   
	while(matcher.find()) {   
	System.out.println(matcher.group());   
                }
 }
}

In my opinion either both is correct or both are wrong (in this case the correct answer is D- None of the above.)
If you think that only B is correct, could you make a sample?
;-)

Thanks

[T. Sharma]

I hope, it will clear all the confusion

import java.util.regex.Matcher;
import java.util.regex.Pattern;
 
 class Regex1 {
        public static void main(String[] args) {
        	//Option A
          if(isMatching("[e-mail]", "\\b\\w+@\\w+\\.com\\b"))
               	System.out.println("Option A is wrong - it accepts email starting from a number");

            //Option B
            if(isMatching("[e-mail]", "\\b\\D\\w*@\\w+\\.com\\b"))
               	System.out.println("Option B is wrong - it accepts email starting from a number");
            else if (!isMatching("[e-mail]", "\\b\\D\\w*@\\w+\\.com\\b"))
            	System.out.println("Option B is wrong - it is not accepting a correct email");
            else 
            	System.out.println("Option B is correct");
           
            //Option C
            if(isMatching("[e-mail]", "\\b\\D\\w+@\\w+\\.com\\b"))
               	System.out.println("Option C is wrong - it accepts email starting from a number");
            else if (!isMatching("[e-mail]", "\\b\\D\\w+@\\w+\\.com\\b"))
            	System.out.println("Option C is wrong - it is not accepting a correct email");
            else 
            	System.out.println("Option C is correct");
        }

		private static boolean isMatching(String str, String regex) {
			Pattern pattern = Pattern.compile(regex);
			Matcher matcher = pattern.matcher(str);
			if(matcher.find()) {
			        return true;
			}
			return false;
		}
}

It results the following:

Option A is wrong - it accepts email starting from a number
Option B is correct
Option C is wrong - it is not accepting a correct email

[Devaney Marcondes]

You're so great, this example clarified my doubts , but the answer B accept white spaces in the middle.

import java.util.regex.Matcher;   
import java.util.regex.Pattern;   
    
 class Regex1 {   
        public static void main(String[] args) {
	String regexA = "\\b\\w+@\\w+\\.com\\b";
	String regexB = "\\b\\D\\w*@\\w+\\.com\\b";
	String regexC = "\\b\\D\\w+@\\w+\\.com\\b";


	print("A", regexA);
	print("B", regexB);
	print("C", regexC);
   
        }   
  

	private static void print(String opt, String regex){
            if(isMatching("[e-mail]", regex))   
                System.out.println("Option " + opt + " is wrong - it accepts email starting from a number");   
            else if (!isMatching("[e-mail]", regex))
                System.out.println("Option " + opt + " is wrong - it is not accepting a correct email");
            else if (isMatching("a [e-mail]", regex))
                System.out.println("Option " + opt + " is wrong - it is accepting email with space.");
            else if (isMatching(" [e-mail]", regex))
                System.out.println("Option " + opt + " is wrong - it is accepting email starting from a space");
            else    
                System.out.println("Option " + opt +" is correct");		

	}

        private static boolean isMatching(String str, String regex) {   
            Pattern pattern = Pattern.compile(regex);   
            Matcher matcher = pattern.matcher(str);   
            if(matcher.find()) {   
                    return true;   
            }   
            return false;   
        }   
}

And it prints:

Option A is wrong - it accepts email starting from a numbe
Option B is wrong - it is accepting email with space.
Option C is wrong - it is not accepting a correct email

If we follow the question literally, the question don't say anything about space, but when I read "to match an e-mail address", I think that couldn't have a space.
Anyway, thanks a lot for your attention.

[Devaney Marcondes]

Another typo mistake to add:
On page 371 instead of:
System.out.println(" Movie " + movieName + "(" + year ")" + " grossed " + revenue );
Must be:
System.out.println(" Movie " + movieName + "(" + year + ")" + " grossed " + revenue );

[Sergey Korytnikov]

I also noticed one "possible" error in Pretest, could you guys please verify whether I am right or not?
Question number 3 in Pretest - description of answer is weird. (Page 36)

I cut the most interesting part of the code. If you do

 		Integer i = 10;
		Integer j = 11;
		Integer k = ++i;
		System.out.println(k == j);

it will print: true

Book says that it doesn't matter how to compare Integer objects (== or equals) - "Java uses sharing of immutable Integer objects, so two Integer objects are equal if their values are equal". Description is not full (wrong). It really does matter. Only objects memory adresses are compared when you use '=='. The only thing why it works for example from the book, my guess - it is because of JVM's Integer cache which is used to store values from -128 to 127 with default JVM settings (it's used by Integer.valueOf(..) as well).

If you try another example

		Integer i = 1000;
		Integer j = 1001;
		Integer k = ++i;
		System.out.println(k == j);

it prints: false

I ordered Ganesh/Sharma's book for next OCP exam and found out that it has serious mistakes. Probably, it's raw. Don't know how I can rely on it now.

[T. Sharma]

Thanks Devaney and Sergey for sharing possible mistakes.

@Devaney: It is a known mistake; you can check the known mistakes here on our blog.

@Sergey: Here is the full description given for the question 3 in the book; partial text may confuse other readers.

"The Integer objects are immutable objects. If there is an Integer object for a value that already exists, then it
does not create a new object again (only if the value of the Integer is between −128 and 127 (inclusive)). In other
words, Java uses sharing of immutable Integer objects, so two Integer objects are equal if their values are equal
(no matter if you use == operators to compare the references or use equals() method to compare the contents)."


We are sensitive to the mistakes in the book; we already revised the book once and fixed a set of mistakes known that time. We maintain a list of errata on our blog and keep updating it. We encourage our readers to post errata on the page, so that we can fix it next time.

[Surya bende]

Hi friends,
Iam preparing for javacertification i.e Oracle Certified Java Programmer(OCJP),Iam confusing regarding the versions of exam .Can anyone help me which version i should take.Is it mandatory to take the latest version.Thanks in advance

[Sergey Korytnikov]

T. Sharma wrote:Thanks Devaney and Sergey for sharing possible mistakes.
@Sergey: Here is the full description given for the question 3 in the book; partial text may confuse other readers.

"The Integer objects are immutable objects. If there is an Integer object for a value that already exists, then it
does not create a new object again (only if the value of the Integer is between -128 and 127 (inclusive)). In other
words, Java uses sharing of immutable Integer objects, so two Integer objects are equal if their values are equal
(no matter if you use == operators to compare the references or use equals() method to compare the contents)."

T. Sharma thank you for your response. I'm not trying to confuse any readers. I ordered my book on Amazon 1+ month ago in advance, before I took OCA exam and opened your book yesterday first time.
In my hard copy I don't see that "(only if the value of the Integer is between -128 and 127 (inclusive))" - that's why I raised the question. Where did you find it? Which page?

You mentioned that you've fixed ebooks, what is hard to do with released paper book.
It's pretty confusing that I can't use ordered book without double checking all errors with forums and websites as I'm not going to spend more money for ebook.
Do you have any thoughts to provide fixed ebooks free to those who ordered hard copies?

[T. Sharma]

Sergey Korytnikov wrote:

T. Sharma thank you for your response. I'm not trying to confuse any readers. I ordered my book on Amazon 1+ month ago in advance, before I took OCA exam and opened your book yesterday first time.
In my hard copy I don't see that "(only if the value of the Integer is between -128 and 127 (inclusive))" - that's why I raised the question. Where did you find it? Which page?

You mentioned that you've fixed ebooks, what is hard to do with released paper book.
It's pretty confusing that I can't use ordered book without double checking all errors with forums and websites as I'm not going to spend more money for ebook.
Do you have any thoughts to provide fixed ebooks free to those who ordered hard copies?

Probably, you received the copy before we fixed first set of mistakes. The text you mentioned ("(only if...)") was added when we fixed first set of mistakes.

Please mail to us ([email protected]), let us see what we can do for you (and readers like you).