Sirish Kumar

Greenhorn
+ Follow
since Jan 28, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by Sirish Kumar

Hi Ranchers,
Well I guess this has become a habit now. I cleared SCJP 1.4 last week. But I was still going through some articles on the net when this question popped up. Have a look at the following code.

As expected line 1 gives a compilation error since the class ShapeClass and Test are not related. Thus the cast fails the compile time check and hence the error.

However line 2 compiles without any errors. Now this was unexpected. I was under the impression that the compile time is also applicable to interfaces as well. So does this mean that the compiler does not perform the compile time check in case of interfaces?? If so , why is it so???

Looking for any inputs
Regards
Sirish Kumar
Hi Ranchers,
Passed the SCJP 1.4 exam today scoring 96%. Extremely pleased abt that. Got 2 questions in threads section wrong. May be that could have been avoided. Anyway I do owe it to Java Ranch. Never knew that learning could be sooo fun....And really after just 2 months of preparation, I really was surprised that I scored so much..
Once again thank you all for making it possible.. Jess in particular for always being there and guiding the new ranchers
Finally although I am posting to the Results forum, I do hope that all my fellow ranchers at the certification forum do have a look since my thanks go out to each of them
Regards
Sirish Kumar
20 years ago
Hello to all,
This question popped up in my mind as I was taking up one of the mock tests.Before the question, just a background of the relevant concepts
Abstract modifier: requires that the method HAS to be overridden
Final modifier: requires that the method CANNOT be overridden
Now with respect to the static methods. Static methods cannot be overridden (only hidden)
Thus abstract modifier cannot be applied to static methods because they cannot be overridden. I therefore expected the same argument to hold good for the final modifier. However it is not so and the final modifier can infact be applied to the static methods..This got me thinking...
Any comments abt this??
Sirish
Hi Sriram,
Yep the link was useful to get the basics right. So that should do as of now..Thanks
-Sirish
Hi ,
Although my explanation is not exhaustive, here are the few thumb rules that you can use to make the decision
----- If you want to specify only the contract and no implementation then go for an Interface. If you want to specify the contract and optionally a partial implemenation then go for the Abstract Class.
----- Interface would give you greater flexibilty than abstract classes.
Firstly in a language like Java which does not support multiple implementation inheritance, using a abstract class would mean that we no longer can extend another class that would be essential as per the design. Thus we have to prefer an Interface over the Abstract Class
Secondly using an Interface would be a more meaningful design decision and would model the real world in a better way.
Consider the following classes:
class Circle{}
class Dog {}
Now in this case there are 2 different class heirarchies with no commonality between them. Suppose we require a contract with the method move() in all the classes. There are 2 options for this
-- We can use an abstract class Moveable with the method move()
abstract class Moveable
{
abstract void move();
}
We can then change the design as follows
class Circle extends Moveable{}
class Dog extends Moveable{}
However this is not a good design because
1. It does not model the real world in the right way. The classes Dog and Circle have nothing in common and should ideally be placed in different hierarchies
2. It does not allow us to extend from another class. In the real world the situation would be as follows
class Shape{}
class Circle extends Shape{}
class Pet{}
class Dog extends Pet{}
this being the case, we can no longer extend from class Moveable at the same time.
Thus the better design in this case would be an Interface as shown
interface Moveable
{
void move();
}
class Shape{}
class Circle extends Shape implements Moveable{}
class Pet{}
class Dog extends Pet implements Moveable{}

Finally although abstract classes and interface are used to leverage polymorphism, it is always better to program to the interface rather than the implementation.
-Sirish
[ February 07, 2004: Message edited by: Sirish Kumar ]
Hello All,
Can anyone please explain the logic behind the output of true, false, true in this code snippet

I could not determine the exact reasons for the behavior
Thanks a bunch
Sirish
Hi Dan,
Thanks for that neat explanation..I agree that the code compiles fine with the new compiler. Hence the options were misleading. May be the mock exam was out dated and the question was drafted with an old compiler that was giving the error.
Thanks again
Hi again Ranchers,
Came across this question in one of the mock tests online

The correct answer was supposed to be option A. My reasoning was that although the access level of main method has to be public , it would not cause a problem during compilation. It's only at runtime that we would get the error that "matching main () method is not found. So I thought that none of the options are valid
However the reason given by the mock exam was that the option A is as per the JLS. Any inputs on this one
Regards
Sirish
Hi Ranchers,
This is with regard to the instantiation of static member classes. I know that to instantiate a static member class, we do not need an instance of the enclosing class. However I thought that instantiating through an instance of the enclosing class was also fine. Hence I tried the following code.

However I got the compile time error "qualified new of the static class" on lines 1 and 2. Line 3 had no such problem since I used the normal syntax for instantiating a static member class.
Since static members of a class can be accessed with / without an instance of the class, I thought the same is applicable to the instantiation of the static member class. However it was not so..Can anyone please provide inputs. My last question on Exceptions is still pending and I am quite apprehensive abt this one ..Hope it's not so
Thanks all
Hi Paul,
No it is not possible to invoke any new methods or access fields that have been declared inside the anonymous class. We can however declare new fields and methods though and the complier would not complain. But this would not be of much help
Anonymous classes do not have a name. So the only way to access the members is through the superclass or the superinterface reference. This being the case, there is no way one can invoke new methods and fields that have been added in the anonymous class(One can however invoke the new methods or access the new fields from within the methods of the superclass though)
Have a look at the example below

class SuperClass
{
int superClassVar = 1;
void superClassMethod()
{
System.out.println("superClassVar : " +superClassVar);
}
}
public class Anonymous
{
public static void main(String []a)
{
SuperClass anonymous = new SuperClass ()
{
//new field
int anonymousClassVar = 10;
//new method
void anonymousClassMethod()
{
System.out.println("anonymousClassVar : "+ anonymousClassVar);
}
//inherited method
void superClassMethod(){super.superClassMethod();//invoke the new method from the inherited methodanonymousClassMethod();}
};
anonymous.superClassMethod();
// Compile time error since new method cannot be invoked
//anonymous.anonymousClassMethod();
}
}
Hope that helps
Hi Raj,
As per my understanding any member (field or method) is inherited unless it is
1.private in the superclass
2.hidden in the subclass OR
3.overridden in the subclass.
Since fields can only be hidden, the static field is inherited if it has not been declared as private in the superclass and also not hidden by another field with the same name in the subclass
Eg:
class Base
{
private static int i; \\not inherited since it is private
public static int j; \\inherited since it is not private
public static int k; \\not inherited since it has been hidden
}
class Derived extends Base
{
public static int k; \\hides the field with the same name in the superclass
}
Hope that helps.
Hi Gian,
Abt the compiler allowing us to specify the checked exceptions in the throws clause. As you say, may be that has been provided so that the clients of the method will not be impacted during later stages of the development when the method is implemented. So to start of with we can just specify the likely checked exceptions in the throws clause of the empty method and get away.
I however could not understand the rationale behind allowing the Exception to occur in the catch clause when the try block is empty. After all the RuntimeException / its subclasses are unchecked exceptions. So it is not mandatory to handle/declare them.
Thanks for getting the ball rolling . My question has been partly answered now.. May be once the big guys/girls step in it would be clear
Hi All,
Sorry for posting the same question again. Sorry for the slip-up. I have got good replies to the same question posted earlier. Please do continue in the old thread and do not post replies to this one
Thanks a bunch
Compile Time error
Hi All,
This is with respect to the exception handling rules. I understand
that any method that can throw a checked exception must take one of the
following approaches
1.Declare the checked excpetion in the throws clause OR
2.Provide the try/catch clause
Now consider the following method
//Approach 1
public void raise() throws IOException
{
//empty method
}

//Approach 2
public void raise()
{
try
{
//empty block
}
catch(IOException a)
{
}
}

While there is no problem with snippet 1, in case of snippet 2 the compiler
reports that the java.io.IOException is not thrown in the body of the
method. I could not understand the difference in this behaviour..
Further if the IOException is replaced with Exception then both the snippets are fine. Again this was not what I was expecting since Exception and all its subclasses (other than the RuntimeException branch) are checked
exceptions.
Any comments regarding the above 2 problems???
Thanks
Hi All,
This is with respect to exception handling. I understand that every method that can throw an checked exception must handle it in one of 2 ways
---- It can declare the checked exception in the throws clause OR
---- It can provide the try/catch block
I noticed this differing behaviour in the 2 approaches.Consider the following method
//Using approach 1
public void raiseException() throws IOException
{
//empty method
}
//Using approach 2
public void raiseException()
{
try
{
//empty block
}
catch(IOException a)
{
}
}
While there was no problem in the first snippet, in case of the second the compiler reports that the java.io.IOException is not thrown..Why is this difference in the behaviour??? This problem remains the same for all the checked exceptions...
Further the problem however is resolved if IOException is replaced with Exception. I was expecting the same behaviour since Exception is also a checked exception.But it was not so...
Any solutions to this one??