Francisco Montes

Ranch Hand
+ Follow
since Sep 30, 2009
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
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 Francisco Montes

Hi Rohan,

I agree with you that they should definitely specify whether they are talking about outer, inner or both type of classes. In a case like this i´d say that they refer to all types of classes.

As for the second question I am not sure why would you need more information to answer but please let us know why do you think that way. I believe the question just wants to test if you know when an object gets locked and when it doesn´t in any of those three possible scenarios.

Francisco
Abiraman,

I was just pointing out that i never saw a concrete method being overriding by an abstract version of it. Is basically like "emptying" the concrete method and force any subclasses to implement it again. I thought that was illegal and turned out it wasn´t, that´s all.

That's true, but when you realize that most abstract classes extend Object -- which is a concrete class -- that observation suddenly becomes less interesting.



Touché Paul hehe
A question from ExamLab with an interesting twist (at least for me).



I thought this code would not compile. Basically because I didn´t know that a concrete method could actually be overriden by an abstract version of it.

Is not that i have a problem with this really. I guess i just have to memorize it as a new rule to learn. But i thought of sharing it with all of you too. So be warned!

Francisco
Hi Javaranch,

A question taken from one of those mock exams that you can do at www.javachap.com.

What can be inserted at // insert code here, to make object created at line 5 eligible for garbage collection?



Possible answers (you can only choose one).
a) arr[0] = null;
b) x = null;
c) arr = null;
d) All of the above

I chose d) thinking that if we do a), b) and c) all together, we will be sure that the object will be garbage collected as all references to it will be cleared.
But they state that c) is the correct answer but if that were the case, we would still have x pointing to the Integer object, wouldn´t we?

That is because... According to the compiler, it is reachable. Keep in mind that the Exception class is a super class of the RuntimeException class, which means that it is possible to catch unchecked exceptions. And since there is no way to check whether an unchecked exception is thrown, the compiler has to assume that the catch is reachable, and hence, what is after the try-catch is reachable.



I was kind of thinking this way too. I also agree that the compiler rules for detecting unreachable code may not be the same ones we think and we have to keep an eye on that.

Then again, i don´t think the SCJP exam will be so picky on this particular issue. At least, i hope so!

Thank you for all for your replies. :-)
Nidhi,

Thank you for sharing your experience about the exam. I will taking it very soon and found your comments very helpful :-)

Congratulations, excellent score!

Francisco
11 years ago
Hi javaranchers,

Sometimes the simplest pieces of code get my attention one way or another:



I would say that the line marked as "Last line" is unreachable. My logic is that there is no execution path that can go around the "return" statement. The finally section will execute and then we will leave the method (return). However the compiler does not look at it the same way.

Am i wrong? and if i´m not: how come that the compiler does not detect the last line as unreachable?

Thanks for you help!

Francisco
Spot on Vijay!

Now i know that i need to use casting to reach a shadowed variable at that level.

Thanks a lot!
Thanks a lot seetharaman.

I was looking for a more "direct way"... something like System.out.println(super.super.s); (I know that it doesn´t even compile but i hope you see what i mean).

From your reply i take that there is no way to access property s in SuperSuperClass from where i was trying to do it.

If I do it the way you suggest, I would be creating another instance of an object and I would be accesing a different value of SuperSuperClass s which is not really what i was looking for.

Does it makes sense?
Hi everybody,

I am testing a few concepts about variable scope and accesibility to shadowed variables from subclasses.
My question is, given the following code, is there a way to access the SuperSuperClass´s string from the commented line?

Thank you!

Look for "Java generics" in Google. You will find lots of resources/tutorials...
Dejan,

I´m sorry but it does not work the way you mentioned. Try this:



This is the output:
Value received in capture method: 20006
Value after calling capture: 20006

So in fact, the expression is completely evaluated before passing its result into the method.
True, I meant "finalize" (oops). Thanks Paul. :-)
11 years ago
My understanding:

An object is eligible for garbage collection as soon as there is no references to it from any live thread.

So, unless you override the finally method of that object and make a reference variable (in a live thread) point to it... it may get garbage collected.
11 years ago
Because it will be not a good practice.