Ryan Slominski

I think if you start playing around with JPA query hints with respect to caching you can probably find a way to disable or clear the cache. For example you can evict all in JPA 2 with:

em.getEntityManagerFactory().getCache().evictAll();

I think some of the caching options depends on your JPA provider (Hibernate, EclipseLink, etc.). More info here: http://wiki.eclipse.org/EclipseLink/Examples/JPA/Caching

Ikpefua Jacob-Obinyan wrote:why do you think E should be a correct answer

You should never explicitly throw an AssertionError because:

You can just use the assert statement (which will delegate to the JVM to throw the Error on your behalf if the condition is met and assertions are enabled)

General best practice says you shouldn't throw an Error (The Java Tutorial says this for example: http://download.oracle.com/javase/tutorial/essential/exceptions/throwing.html).

Dennis Deems wrote:C and E, are imperatives which can be neither true nor false

Nice observation. Now that you point it out, it IS a poorly worded question! Even still, I think I understand what C and E are "saying", and I think E should be true.

The entire question from the MasterExam is:

Which are true? (Choose all that apply.)
A It is not good practice to place assertions where you think execution should never reach.
B It is sometimes appropriateto call getters and setters from assertions.
C Use assertions to verify the arguments of private methods.
D Assertions can be disabled for a particular class.
E Never throw an AssertionError explicitly.

The reported correct answer is C & D. I also think E should be a correct answer. The explanation for why E is not a correct answer appears to be missing. The Reference simply says:

E is also incorrect.

ogeh ikem wrote:Autoboxing is a widening conversion.

Umm... no?

Autoboxing is simply converting a primitive to an object or object to a primitive automatically: the compiler inserts the primitive-to-wrapper method call (for a box), or wrapper-to-primitive method call (for an unbox) automatically. For eample, Integer.valueOf for a box or Integer.intValue() for an unbox.

Deepak Bala wrote:I did not understand what you meant by method matching.

Method matching is the process of determining which overloaded method to call. For example which method gets called:

public static void go(short... s) {} public static void go(Number n) {} public static void main(String[] args) { short s = 7; go(s); }

Deepak Bala wrote:Henry has provided an example in that link above. Viewed in that perspective you *could* say that is-a relationship was involved in an autoboxing

The example is again of autoboxing followed by a widening, which are two independent things. In his example, method matching isn't used; a method is simply boxing and then widening and returning the result.

ogeh ikem wrote:This is a special case scenerio where autoboxing involves not only boxing an int to an Integer, but also involves a widening conversion to a Number.

This is actually two separate things: autoboxing and then widening. That is my point: widening is NOT part of autoboxing so saying that inheritence plays a role in autoboxing is plain wrong.

The LearnKey MasterExam practice test B question 52 (Bundled with SCJP for Java 6 Study Guide book by Kathy Sierra and Bert Bates) asks to check all that are true and reports the following as a correct answer:

D In some cases, is-a relationships are used in the process of autoboxing.

This seems like a really bad answer. The explanation given is:

... you can autobox an int to a Number (via an Integer).

This expanation is describing an autobox followed by a widening, which can occur with method matching. The widening and autoboxing are two independent things, which don't depend on each other. However, a method matching process may depend on each to occur. Perhaps the statement should read something like "In some cases, is-a relationships are used in the process of method matching."

Dennis Deems wrote:You would never write that code in real life

But isn't your example just as unlikely: if (x <= 0) throw new AssertionError();

Dennis Deems wrote:A NullPointerException will happen any place the code calls a method on a null object, regardless of the programmer's wishes

Actually, I think we agree here: a developer has more control over an AssertionError than any other JVM Error. I guess what we still disagree about is whether that means it is being thrown "programmatically".

Another interesting question is whether a RuntimeException or Error should ever be thrown programmatically. It is almost like saying your program just gives up by design (since a RuntimeException or Error generally isn't something you can recover from).

As was already pointed out you can make the same argument with NullPointerException (which is reportedly thrown by the JVM):

String s = null; if(s == null) throw new NullPointerException(); s.length();

vs

String s = null; s.length(); // Just let the JVM throw the NullPointerException (it's simpler and more graceful)

The argument for the programmatic camp appears to be that the application developer has a certain amount of control over an AssertionError; In other words the application developer can choose to include AssertionErrors or leave them out (or turn them off at runtime). This characteristic of AssertionError does give it some ground on the thrown programmatically side (perhaps to say it indirectly is thrown by the developer), however, it seems to me that it still fits the thrown by JVM side more easily.

This is an interesting debate since any Throwable can be thrown programmatically. I wonder if making the (apparently subjective) distinction on a certification exam actually has any value, at least as far as AssertionError is concerned?

Dennis Deems wrote:It's not like a Stack Overflow or an Illegal State.

Not sure what you mean; StackOverflowError is an Error thrown by the JVM and IllegalStateException is an Exception thrown programmatically.

Just look at the JavaDoc API: http://download.oracle.com/javase/6/docs/api/java/io/Console.html

You'll see that if you use the readPassword method that the user's keystrokes are not echoed. If you wanted to echo the user's keystrokes you could use the readLine method instead (which means you would also get a String, not a char[]).

Bert Bates wrote:I'd really like to hear other opinions

I'm going to have to side with the AssertionError is thrown by the JVM camp. There are two reasons why this makes more sense:

Generally Errors are thrown by the JVM (I don't know of any Error that is appropriate to throw in program code)

It is simpler to define "programmatically" as meaning literally using the "throw" reserved word in program code

Rationalizing AssertionError being thrown programmatically is too much work - you have to first agree to be an exception (no pun intended) to the rule - don't throw an Error. Then you have to agree that the definition of "programmatically" is a developer's premeditated intent, which is much more complex and subjective.

Of course if I get this question on the certification exam I'll know from Table 5-2 of your Study Guide to answer that AssertionError is thrown programmatically!

Dennis Deems wrote:One can only conclude that it simply isn't considered very important.

Really? On a Java community forum focused on certification you think the practice test quality isn't something to take seriously?

sagar shroff wrote:Hey Can someone explain why multiple errors.

The first error is because the method System.getConsole doesn't exist. It should be System.console(); The second error is that Console.readLine returns a String, not a char[].

I recently ran into this MasterExam question error. I just downloaded the bonus practice exam within the last month so I'm surprised to see such a blatant error still hasn't been corrected.

Also, did I miss it, or is there still no official errata list?

So far the best I found was the topic here: https://coderanch.com/t/467890/java-programmer-SCJP/certification/Compiling-errata-SCJP

This topic is about the discrepancy on the MasterExam practice tests and whether has-a relationship applies to class variables or not (the last two posts are off-topic).

I've found the answer I was looking for and I'm updating this thread since it was the first hit on my Google search and others may find this thread as well.

After doing some more searching on this forum it turns out this has been discussed many times before and the best response appears to be from the book's author (Bert Bates): https://coderanch.com/t/424673/java-programmer-SCJP/certification/Master-Exam-Error

In summary: has-a relationships do apply to class variables as well as instance variables, though it is acknowledged as a gray area. Bert also indicated that it is unlikely this distinction will arise on the real exam.

This is an old topic, but it is still relevant since questions from K&B 5 were apparently reused for K&B 6. I ran into this same issue with the latest K&B Java 6 book with MasterExam software. As stated already one of the practice tests makes a clear distinction between instance variables and class variables and that they both can be used in composition. This is also supported by the Java Turorial: http://download.oracle.com/javase/tutorial/java/nutsandbolts/variables.html. However, a later practice test question has the following reportedly correct answer:

"B: Has-a relationships always rely on instance variables."

This isn't right...

Note: the MasterExam software doesn't tell you what the question number is when you're reviewing the "study guide" it prints after you finish the test so I don't have the question number readily available, but I do know it came from the third practice test (test C). The study guide also doesn't show you what the answer choices were and MasterExam crashes if you minimize the window and then put the computer to sleep, but that's another topic.

If I am understanding your response correctly you are saying that there is no way to avoid a utility method with an enum?

I'm currently using a utility method, but I was wondering if there was a better way since there is a shortcut for a collection (var attribute).