aspose file tools*
The moose likes Mock Exam Errata and the fly likes Enthuware errors. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Mock Exam Errata
Bookmark "Enthuware errors." Watch "Enthuware errors." New topic
Author

Enthuware errors.

Emanuele Ghe
Ranch Hand

Joined: Feb 04, 2009
Posts: 111
Since noone reads the Enthuware official forum, I'll post errors I've found in the mock tests here:


com.enthuware.ets.scjp.v6.2.274 :

garbage collector will call finalize AT MOST 1 time, so the question and answer are wrong.


com.enthuware.ets.scjp.v6.2.304:
there are 2 correct results for this question:
int,long
and
float,double

but the test suite marks only float,double as correct, even if in the explanation is clearly stated that also int,long is correct.

SCJP6 with score 90%. I am conscious of my ignorance and ready to learn from everyone.
Paul Anilprem
Enthuware Software Support
Ranch Hand

Joined: Sep 23, 2000
Posts: 3199
    
    2
Hi Emanuele,
Thanks a lot for your feedback.

2.274: I don't see anything wrong with it. Could you please post the question in its entirety? Also, please make sure you are using the most recent version ( 1.32 ) of the question bank.

2.304: The given asnwer is correct. As the explanation says int and long are also correct. But they are not among the options, double and float are. The question is not asking for all the correct options either. All correct possibilities may not necessarily be provided in the options so you need to select which ever are correct. But I can see that it is causing confusion. Would you like a suggest a way to reword it? We would be happy to improve it.

We will try to do a better job with the forum

HTH,
Paul.

Enthuware - Best Mock Exams and Questions for Oracle/Sun Java Certifications
Quality Guaranteed - Pass or Full Refund!
Emanuele Ghe
Ranch Hand

Joined: Feb 04, 2009
Posts: 111
Hi Paul,
first I wanna congratulate you for your software. It helped me a lot and I think it's worth its money.

Anyway, for question 2.274, this is your explanation:
"Statement 3 is the only thing guaranteed by the JVM. Pay attention to the words...it does not say that an Object will be GCed or the likes. All it says isthat IF ever an object is actually being destroyed by GC then before destroying it, its finalize() method will definitely be called."

This answer is WRONG. The garbage collector could skip some objects. The only thing guardanted is that the finalize() will be called AT MOST once, but it could be not called.



For question 2.304, this is your explanation:
"Note that none of the terms in the expression 1 - rate/100*1 - r/100; is double/float. They are all ints. So the result of the expression will be an int.
Therefore, amount can be int, long, float or double"

but the only answer you mark as correct is "double or float", but also "int or long" is correct, as you explain in your explanation.



I hope this helps improving the software.

Thanks.
Paul Anilprem
Enthuware Software Support
Ranch Hand

Joined: Sep 23, 2000
Posts: 3199
    
    2
Hi Emanuele,
Thanks again for your response. I am glad to hear that you liked our s/w.

Emanuele Ghe wrote:Hi Paul,
first I wanna congratulate you for your software. It helped me a lot and I think it's worth its money.

Anyway, for question 2.274, this is your explanation:
"Statement 3 is the only thing guaranteed by the JVM. Pay attention to the words...it does not say that an Object will be GCed or the likes. All it says isthat IF ever an object is actually being destroyed by GC then before destroying it, its finalize() method will definitely be called."

This answer is WRONG. The garbage collector could skip some objects. The only thing guardanted is that the finalize() will be called AT MOST once, but it could be not called.


You are right that an object may be skipped by the GC. However, the explanation is talking about a different point. It says, "IF ever an object is actually being destroyed ... ". There will be no case when the objected is actually destroyed by the GC without calling finalize.


Emanuele Ghe wrote:
For question 2.304, this is your explanation:
"Note that none of the terms in the expression 1 - rate/100*1 - r/100; is double/float. They are all ints. So the result of the expression will be an int.
Therefore, amount can be int, long, float or double"

but the only answer you mark as correct is "double or float", but also "int or long" is correct, as you explain in your explanation.



I hope this helps improving the software.

Thanks.


Again, please look at other options. They clearly specify "Only double" or "Only ...". While the correct option says "double or float". So the question is not saying that double or float are the only correct possibilities. It is saying that float and double are correct. The fact that int are long are also correct is irrelevant here. Had int or long been an option, and had it been not marked as correct, then that would be wrong. The explanation just provides additional info about why int and long are also correct. But again, just because they are correct doesnt mean the question has to list them among its options. The question does not claim to present ALL correct answers among its options. You need to select which ever options are correct. Whether there are other possible answers (beyond the presented options) is irrelevant, imho.

HTH,
Paul.
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1613
    
  10

Paul Anilprem wrote:Hi Emanuele,
Thanks again for your response. I am glad to hear that you liked our s/w.

Emanuele Ghe wrote:Hi Paul,
first I wanna congratulate you for your software. It helped me a lot and I think it's worth its money.

Anyway, for question 2.274, this is your explanation:
"Statement 3 is the only thing guaranteed by the JVM. Pay attention to the words...it does not say that an Object will be GCed or the likes. All it says isthat IF ever an object is actually being destroyed by GC then before destroying it, its finalize() method will definitely be called."

This answer is WRONG. The garbage collector could skip some objects. The only thing guardanted is that the finalize() will be called AT MOST once, but it could be not called.


You are right that an object may be skipped by the GC. However, the explanation is talking about a different point. It says, "IF ever an object is actually being destroyed ... ". There will be no case when the objected is actually destroyed by the GC without calling finalize.


That's a lie . I can think of two cases:

Situation A
1. Object becomes available for GC.
2. GC comes by and calls finalize()
3. something happens to the object because of the method, making it active again
4. Object becomes available for GC a second time.
5. Object destroyed, sans the finalize() call (it already was called!)

Situation B
1. A manual call to finalize() happens -- not good practice
2. Object becomes available for GC
3. Object is destroyed without GC calling finalize()

I think the bottom line here is, the finalize method can only run AT MOST one time per object. There is no guarantee that it will be concurrent with the destruction of the object, or even that it will be called by the GC.

The answer/explanation, I think, takes into accounts all normal situations, not the exceptions to the rule.


When you do things right, people won't be sure you've done anything at all.
Paul Anilprem
Enthuware Software Support
Ranch Hand

Joined: Sep 23, 2000
Posts: 3199
    
    2
Hi Janeice,
Your scenario in B is incorrect. Manual call to finalize has no bearing on Garbage collector's call to finalize(). So if the GC is actually destroying an object, it can be assumed that GC has called finalize (either just now or in the previous cycle) and that is what the question is getting at.

HTH,
Paul.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Enthuware errors.
 
Similar Threads
Clarification about Widening
Kathy's book - chapter 6 - question #7
Primitive
Operator - operands
Simple weird String assignment