Ranjan Chaudhuri

Ranch Hand
+ Follow
since May 22, 2001
Merit badge: grant badges
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ranjan Chaudhuri

Could someone let me know what the current registration fee is (within the U.S.) for the IBM/XML certification exam.
The IBM and Prometric sites didn't have this information readily available, and I didn't want to go through the Prometric registration page to find out.
Actually, I think Zeeshan is correct in his first assertion--interface methods are considered to be (implicitly) abstract. It is even possible (although discouraged) to use the "abstract" modifier with them. See JLS 9.4 for details.
However, interface methods can't be static _because_ they are abstract (static methods can't be overriden). Member types (classes and interfaces) within interfaces are considered to be implicitly static and public though--they would have to, as interfaces can't be instantiated.
Intuitively, I agree and that's what I always assumed. But I would be much happier if someone could show me (preferably using the JLS), why the (int) version is more specific than the (double) version in the above case, or even in the simpler one below. It's probably something as simple as the fact that requiring a widening conversion makes the (double) version less specific. BUT IN THAT CASE, this should be so even if the (int) version is in the superclass and the (double) version is in the subclass, no? I keep thinking there's some sort of inconsistency here.
I think looking at the JLS too closely has confused me.

[This message has been edited by Ranjan Chaudhuri (edited June 20, 2001).]
You aren't overriding the method, you are OVERLOADING it. But there's still something fishy about it. It is OK for the compiler to report an ambiguity, I suppose, because the value passed (3) matches the signatures of both the int and double methods, one in the subclass and one in the superclass.
(See JLS 5.3 and 5.1.2 for the relevant parts on widening conversions.)
However, moving both methods to the superclass shouldn't then RESOLVE the ambiguity in favor of the (int) method! (Unless somehow having them both in the same method helps the compiler disambiguate by figuring that the (int) version is more specific now, but why should the overloaded method being inherited make a difference?)In fact, Sections 15.12.1, 15.12.2, and of the JLS suggest that the ambiguity should still exist. If the (int) method in the superclass is applicable and accessible, so should the (double) method be!
I get the same error as you with 1.3.1--but with the fastjavac compiler, the error I get is *different*, namely "No method found matching method1(int)". I think this is a strange situation, possibly a compiler bug. Perhaps someone else can verify this. I simplified your code to isolate the problem, and used the following:

The error I got at line 24 was "No method found matching amethod(int)."
Again, the way I interpret the relevant sections of the JLS (see 15.12.1 and 15.12.2), there should be no problem, as it is stated in that "method definitions inherited from superclasses and superinterfaces are included in this search [for an appropriate method signature]."
In my case, what seems to be happening is that the superclass method is somehow getting "shadowed" by the method of the same name as the subclass, which shouldn't happen. (Removing the method from the subclass altogether or moving it to the superclass "solves" the problem here too--the (int) version of the method gets called.)
Does anyone else come across this? What happens when you compile it on JDK 1.2.1 or on non-Sun compilers? [I got the same behavior with jikes, i.e. ambiguous when the double and int versions are in different classes, and no problem when both are in the superclass, with the int version being selected when passed an int.] Am I misreading the JLS? Compiler bug in both cases?
[This message has been edited by Ranjan Chaudhuri (edited June 20, 2001).]
[This message has been edited by Ranjan Chaudhuri (edited June 20, 2001).]
[This message has been edited by Ranjan Chaudhuri (edited June 20, 2001).]
I was a bit confused at first too, but what Manfred quoted from the API in effect says:
(1) The Object class DOES NOT implement the Cloneable interface.
(2) The Object class DOES implement (i.e. have) a clone() method.
This method is accessible (in the usual way) by any class "X" that directly extends Object (i.e. it doesn't extend anything else), overrides the method, and then calls super.clone().
Such a class DOES NOT have to implement the Cloneable interface itself to access the overridden method from its parent (Object). But it COULD access it even if it did implement Cloneable and define its own clone() method.
However, if the class in question extends some other class (i.e. is not a direct subclass of Object), then you will not be able to access the clone() method in Object.
Hope that helps,
I've been using JQ+ this past week, and wanted to know how closely the GUI approximates the actual one used in the examination. In particular, does the exam. have a "Review" button (and so on)?
Thanks, Ranjan
Thanks Kanchan and Bin.
I need to learn to read the COMPLETE #$%^& question!
Anyway, to confirm what you say with a quote from the JLS(8.2)
"Constructors, static initializers, and instance initializers are not members and therefore not inherited."
True or False:
You can only call public and protected constructors of the superclass in a subclass if the subclass is not in the same package because only those are inherited.
If the answer is "False," please provide an example to illustrate.
Let me take a crack at answering my own question, since the JLS is never wrong.
It must be that what is being returned is a local final variable. That would compile too, and then everything is consistent.
This would suggest that Mughal Sec. 7.5 is inaccurate, and answer #5 is correct.
I will send a note to Mughal.
Thanks, Paul
Hi Paul,
That was a good question, though I still have problems interpreting one choice, #4.
#1 is great and mind-expanding.
With #5, I still have a problem. In my interpretation, JLS 8.1.1 doesn't say that anonymous classes cannot be static. And JLS 8.5.2 does not rule this out either, but just specifies the use of the "static" keyword.
In fact, the following code (adapted from Mughal, Sec 7.5) would seem to suggest otherwise:

Since no instance of Test was created, it must be that the anonymous "A"
returned in main() must be static. Otherwise an error about making a reference to a non-static variable would arise.
Am I missing something?
[This message has been edited by Ranjan Chaudhuri (edited June 12, 2001).]
Right, I interpreted this the same way as you, Bin.
I originally settled for #2 as the only correct answer, and only later noticed that you were supposed to pick *3* choices.
Maybe it was intended as a single correct choice question and there was a typo?
Dave, Sathi:
I was having problems with the wording too.
If I was forced to guess, I would make the same choices.
However, I seem to be having lots of problems... you've noted
some. With respect to Choice #5, I guess an anonymous class could be (implicitly) static if it were included in a top-level nested class? Or would that disqualify it as an "inner class"?
I think this question needs to be clarified somehow.
This one is getting the better of me:
Which of the following statements regarding inner classes is true?
Select all 3 correct choices:
1. A non static inner class may have static members.
2. Anonymous inner classes cannot have any 'extends' or 'implements' clause.
3. Anonymous inner classes can only be created for interfaces.
4. Anonymous inner classes can never have initialization parameters.
5. Anonymous inner classes cannot be static.
There are 3 correct choices?