Chris Heinz

Greenhorn
+ Follow
since Jul 07, 2014
Chris likes ...
Eclipse IDE Java
Cows and Likes
Cows
Total received
1
In last 30 days
0
Total given
0
Likes
Total received
16
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Chris Heinz

Page 872 Chapter 15 code snippet at top of page



I don't believe this code snippet would run as the column referring to a price is called two different things. One of them(whichever is not the actual column name) would cause a SQLException. See "UnitPrice" in the String query and "Price" in the getFloat method. Edit: Now that I went back and looked at the database that this chapters examples are following, "UnitPrice" is the incorrect one. The correct column name is "Price" as seen on page 849.

Also, "from" in the String query is not capitalized. Should be "FROM".
Page 871 Chapter 15

Just a simple typo...

End of the first paragraph:

For the exam, we recommend you focus on the most common SQL data types and the ResultSet methods shown in Table 15-7.



Bolded should be Table 15-8.

John Mercier wrote:I believe the "snapshot" is the original array not the new copy created when a modification is made. When an iterator is created it has a reference to the internal array. If a modification is made while the iterator is still in use the internal array will change to a copy but the reference the iterator is using will point to the original array not the copy. I hope that makes sense.



Oh, I think I see what you are saying...

When the iterator() is called, it uses a reference to the array at that time, but a new copy of the array is not created at this time. A new copy of the array is only created when add() or remove()(possibly others as well) is called. At that time the mutation occurs, the the new mutated copy is used by the CopyOnWriteXxx, but the iterator still references the old copy, before the mutation.

If that's what you were saying, then that makes total sense and I agree with the answer provided in the book. Thanks, John!
With several years of C/C++ experience, but no java experience, it took me about 2-3 weeks to prepare. I used Mala Gupta's OCA prep book as well as K&B SCJP6 as references.

Disclaimer: Actually, it took several months to prepare because I would only study a couple days per week and only for a couple hours each time. I estimate the total hours spent studying was around 100, so that's where I came up with the 2-3 weeks.

Which methods from a CopyOnWriteArrayList will cause a new copy of the internal array to be created? (Choose all that apply.)
A. add
B. get
C. iterator
D. remove



The correct answer is:

A and D are correct. Of the methods listed, only add and remove will modify the list and cause a new internal array to be created.
☐✗ B and C are incorrect based on the above. (OCP Objective 11.1)



According to the API for CopyOnWriteArrayList:

The "snapshot" style iterator method uses a reference to the state of the array at the point that the iterator was created. This array never changes during the lifetime of the iterator, so interference is impossible and the iterator is guaranteed not to throw ConcurrentModificationException. The iterator will not reflect additions, removals, or changes to the list since the iterator was created. Element-changing operations on iterators themselves (remove, set, and add) are not supported. These methods throw UnsupportedOperationException.



Doesn't the above definition for "snapshot" style of the iterator indidcate that a copy of the array was made when iterator() was invoked? If yes, should C also be a valid answer in the question above? Thanks to anyone who helps clear this up!
Hi Akhter and welcome to the ranch!
First, the line number where the null pointer exception is given to you here:



I would suggest reviewing array initialization to figure out what your issue is here... ;)
3 years ago

Matthew Brown wrote:In every question I've seen, only those things that are absolutely guaranteed should be assumed.



Thanks, Matthew!
In several places in the Thread chapter(page 767 first bullet, page 734 last paragraph), the authors state something similar to the following:

The closest thing to a guarantee is that at any given time, when a thread is running, it will usually not have a lower priority than any thread in the runnable state. If a low-priority thread is running when a high-priority thread enters runnable, the JVM will usually preempt the running low-priority thread and put the high-priority thread in.



Does this mean that for the purposes of the exam, that we are supposed to assume that this is guaranteed or not? They go out of their way to say that this is the closest thing to a guarantee, but still stick some of those "usually" modifiers into these descriptions. This leads me to believe that these are not actually guarantees, but for the purposes of the exam, what is the "correct" way to think of this?
Page 766 Chapter 13 Threads 4th bullet

When the sleep or wait is over, or an object's lock becomes available, the thread can only reenter the runnable state. It will go directly from waiting to running (well, for all practical purposes anyway).



Should the bolded be, "It will go directly from waiting to runnable"?

From what I've read about threads, it's not possible to go from waiting to running, but I'm also not completely clear on what the, "(well, for all practical purposes anyway)" comment is intended to mean, so maybe it is valid, but I'm not understanding this comment in the correct context...
HI Shri,
Your guess is correct. Starting with the OCAJP SE7 Programmer 1 certification is your best bet right now. The OCA SE8 is still very new and I believe this test is not even 'official' yet. Plus, there are very few study materials for this test. Have a look in this thread as well for some other responses to your very same question...http://www.coderanch.com/t/644173/java-programmer-SCJP/certification/Java-Certification

K. Tsang wrote:What exam are you preparing?

The OCPJP6 exam definitely have such questions.

The OCAJP7 and OCPJP7 do not have such questions according to the exam objectives.



Hi K,
Thanks for the reply. I realized these were not OCPJP7 topics after I made this thread. Before testing, I might just read up on this topic anyway just to be safe.
My apologies for starting this new thread before using the search function thoroughly. I just saw that the classpath topic is addressed on the cd for the K&B7. These topics were on the scjp 5 and 6, but are no longer current ocpjp7 topics. You never know though, it can be added back at any time :/ I guess I'll just invest some time in studying this topic to be safe.
Has anybody run into questions on this exam asking about the CLASSPATH variable and where a .jar file is located?

I didn't see these particular topics in any of the books I've been using to study. Also, didn't expect these types of questions based on the exam topics on oracle that I've seen. However, I just took the 'Java Class Design' mock test from whizlabs and there were several of these questions on there and they caught me by complete surprise. I don't mind studying this topic, but just wanted to hear from people who have already taken this test if these questions are in fact, on the exam. I have plenty other exam topics that I need to concentrate on if this is not necessary. XD Thanks!
Chapter 10 Self Test Question #3

3. Given:


Which design pattern or principle is implemented?
A. Coupling
B. DAO
C. Factory
D. IS-A
E. Object composition
F. Singleton

Correct answer on page 571 is declared as: 3. ☑ F is correct. The singleton pattern is identifiable by the static variable for the single instance and the accessor returning it.

The class above does not declare a constructor, therefore it will use the compiler generated default constructor which would be . In this case, a public constructor would allow multiple instances of this class to be instantiated. As stated on page 552, "If the constructor weren't private, we wouldn't have a singleton. Callers would be free to ignore getInstance() and instantiate their own instances. Which would leave us with multiple instances in the program and defeat the purpose entirely."

Consider adding a private constructor to the F class.