Guilherme Bazilio

Alexander Shrago wrote:

Guilherme Bazilio wrote:interface Floozel extends Jammer, Floozet { }

Java does not support multiple inheritance! So answer D is false!

There are no problem for an interface to extend many interfaces. Check it!

You're totally right!

interface Floozel extends Jammer, Floozet { }

Java does not support multiple inheritance! So answer D is false!

The ++ sign is an increment operator (assignment). Used to modify (increment in one) the variable.

x++;
This snippet willl only modify the value of x variable after it's current value has been used. So in that if statement it will be evaluated to 2.

++x;
On the other hand, this one will modify (increment) the x variable before using it. Then it comes to be 3 in the if statement.

++ modifies the variable!

The + sign is just an arithmetic operator used to sum values and return the result. So x + 2 will be returned to any variable that wants to receive it.

int y = 0; int x = 2; y = x + 2;

After that code, y will be 2. In the if statement, the result of the sum is not assigned to any variable. The variable x keeps its value since we are not assigning any value to it.

I might be wrong, but seems there is no overriding in Paterson's example. Right guys?

Once eat(String) and eat(int) works as overloaded methods, because we are just changing it's signature, overring does not apply here. There is no "same" (name + arguments) method here.

This topic discuss about static and dynamic polymorphism. It's really interesting and "opened my mind".

Seems like it's only a matter of concepts (with different names).

Compile Time Polymorphism seems to be the same as Static Polymorphism which seems to be the same as Early Binding.

Runtime Polymorphism seems to be the same as Dynamic Polymorphism which seems the same as Late Binding.

But, as far as I've understood, polymorphism is: something that assumes many forms.

And..as it seems, polymorphism in java is: an object from the heap that can be referenced by different variables types (once it extends or implements that class).



What do you guys think?

Because book said isn't a good reason, for sure, but the book itself presented and proved really good reasons for that.

What sources did you read or what makes you think that there is a "compile time polymorphim"? For now, I just can't think of polymorphim being at compile time!

Let me "open my mind"! Hehe

Thanks!

Seetharaman Venkatasamy wrote:

saloni jhanwar wrote:

Seetharaman Venkatasamy wrote:
In overloading concept why we are using same name?

technically method name is its signature. signature = method name and the parameter list (ordered)

Reading Sierra's book, in chapter 2 is said: "Polymorphism applies to overriding, not to overloading."

And, as Seetharaman wrote, method is not identified only by it's name, but name + argument list. And invocation of these methods is based on the type of the actual instance on the heap, which is only possible to happen at runtime!

Hey there guys,

I'm also studying for the exam and I remember to have read something about Strings.

gurpeet singh wrote:

had you created strings "literally" then you would have got true in that case.

Seems like String objects uses something like a "pool of Strings".

As you explicitly (using new keyword) created two String objects, then the pool was discarded.

Can anyone confirm if it's right?

Thanks!

The correction of the compiler error depends on whether you handle the exception or not.

Adding the throws clause to the overriding method will not solve the problem.

When you call the method, the reference used is of type SuperClass and SuperClass' doIt() method throws an Exception that you must handle when calling the method. This is what the compiler checks for. If the compiler sees that you don't handle the Exception thrown, so you'll get an error.

Is that more clearer? Post again anyway.. :P

Thanks!

pavithra srinivasan wrote:
you can throw same exceptions or narrower once or runtime exceptions.. or not throw any exceptions at all but when you don't throw(declare or handle) exception.. then calling method i.e, main method must handle it!

Even when the overriding method throws a valid exception, you would have to handle that.

;P

Mumtaz Khan wrote:
This will give compile time error as exception has to be handled or the main method should declare throws clause.

Mumtaz is correct.

The reference type determines the methods you can call. As the reference sb is of type SuperClass, the compiler assumes you are trying to invoke the SuperClass' method doIt(). As that method throws an Exception, you have to deal with that on the call.

In runtime, it checks the object type and invokes the overriding method, that will not throw any exception.

Is that your doubt pavithra srinivasan?

As K&B said in the book, "think static = class, nonstatic = instance"

That make things more clearer ;P

Ok.. I think I got it clear.

The protected modifier I can imagine some uses as it isn´t so restrict like private. :P

Thanks again!

Maduranga Liyanage wrote:
Yes. In this context, it doesn;t matter if the method was static or not. The behavior is the same.

Thanks Liyanage. I think I got it now.

I think I got what you meant, Maduranga Liyanage.

Let's use sara adrem's example (keeping it's comments):

class TestStatic { private static void staticMethod() { } //This method can be called only from within this class TestStatic void testStaticMethod() { TestStatic.staticMethod(); //Yes can be called } } public class AnotherClass { public static void main (String [] args) { TestStatic.staticMethod(); //NOOOOOOP. not possible. private modifier declared on the static method stops it. } }

If staticMethod() cannot be accessed outside the class because it's private, so why does it needs to be declared static? What if it was a non-static method?

I got confused too. ;P

Thanks!