Home.... | log in.... | Pub my question! | Sign-up....

Java-index >> Other Topics >> Patterns & OO Design

method overloading doubt

In java ,Is method overloading is a compile time polymorphism ?I mean all those method calls will be decided at the time of compilation .. am i right ?

[165 byte] By [HelloTamilaa] at [2007-10-2 10:20:03]

«« Searching for Jeanbeans
»» Does applicaton code requires recompile on changing a jar file

# 1

Hi,I don't think so.That's Dynamic Link.Regards,Sebastien Degardin

sdegardina at 2007-7-13 1:49:29 >

top of Java-index,Other Topics,Patterns & OO Design...

# 2

yes, oveloading is compile time.

ashutoshmcaa at 2007-7-13 1:49:29 >

# 3

Hi,

Here is what Sun says.

"The Java language's portable and interpreted nature produces a highly dynamic and dynamically-extensible system. The Java language was designed to adapt to evolving environments. Classes are linked in as required and can be downloaded from across networks. Incoming code is verified before being passed to the interpreter for execution.

Object-oriented programming has become accepted as a means to solve at least a part of the "software crisis", by assisting encapsulation of data and corresponding procedures, and encouraging reuse of code. Most programmers doing object-oriented development today have adopted C++ as their language of choice. But C++ suffers from a serious problem that impedes its widespread use in the production and distribution of "software ICs". This defect is known as the fragile superclass problem.

Regards,

Sebastien Degardin.

sdegardina at 2007-7-13 1:49:29 >

# 4

method overloading is resolved at compile timemethod overriding is resolved at runtime

Torajiroua at 2007-7-13 1:49:29 >

# 5

http://forum.java.sun.com/thread.jspa?threadID=698143&tstart=0- Saish

Saisha at 2007-7-13 1:49:29 >

# 6

> Hi,

> Here is what Sun says.

> "The Java language's portable and interpreted nature

> produces a highly dynamic and dynamically-extensible

> system. The Java language was designed to adapt to

> evolving environments. Classes are linked in as

> required and can be downloaded from across networks.

> Incoming code is verified before being passed to the

> interpreter for execution.

> Object-oriented programming has become accepted as a

> means to solve at least a part of the "software

> crisis", by assisting encapsulation of data and

> corresponding procedures, and encouraging reuse of

> code. Most programmers doing object-oriented

> development today have adopted C++ as their language

> of choice. But C++ suffers from a serious problem

> that impedes its widespread use in the production and

> distribution of "software ICs". This defect is known

> as the fragile superclass problem.

> "

> Regards,

> Sebastien Degardin.

It seems to me that this quote has nothing to do with the topic at hand.

dubwaia at 2007-7-13 1:49:29 >

# 7

Hi, Sorry, i thouth this was related to this discussion.I was to much tired when i wrotte this.however, this could be interesting. http://www.janeg.ca/scjp/overload/poly.htmlRegards,Sebastien Degardin.

sdegardina at 2007-7-13 1:49:29 >

# 8

> In java ,Is method overloading is a compile time

> polymorphism ?

> I mean all those method calls will be decided at the

> time of compilation .. am i right ?

I would suppose that it depends on how one interprets it.

An overloaded method is still resolved at run time because all non-static, non-final methods are.

However the compiler is going to determine that a particular signature is correct at compile time. And one might suggest that that is what overloading really means.

jschella at 2007-7-13 1:49:29 >

# 9

> I would suppose that it depends on how one interprets

> it.

> An overloaded method is still resolved at run time

> because all non-static, non-final methods are.

The overloading is not evaluated at runtime. Which overloaded method is used is determined by the compiler based on the compile time type(s) of the parameter(s).

Also, there is nothing in the JLS that states that final methods are not virtual. In fact, it implies that the compiler cannot staticly bind calls to final methods because removing final should not cause binary incompatibilities. The VM can inline such calls but it can inline lots of other things too.

dubwaia at 2007-7-13 1:49:29 >

# 10

> > I would suppose that it depends on how one

> interprets

> > it.

> >

> > An overloaded method is still resolved at run time

> > because all non-static, non-final methods are.

> The overloading is not evaluated at runtime. Which

> overloaded method is used is determined by the

> compiler based on the compile time type(s) of the

> parameter(s).

As I said it is still a matter of interpretation.

> Also, there is nothing in the JLS that states that

> final methods are not virtual. In fact, it implies

> that the compiler cannot staticly bind calls to final

> methods because removing final should not cause

> binary incompatibilities. The VM can inline such

> calls but it can inline lots of other things too.

Actually I was just going off the name lookup which I was supposing final methods didn't use (with no references at hand I must guess.)

jschella at 2007-7-13 1:49:29 >

# 11

> > The overloading is not evaluated at runtime.

> Which

> > overloaded method is used is determined by the

> > compiler based on the compile time type(s) of the

> > parameter(s).

> As I said it is still a matter of interpretation.

I think in terms of the OPs question, it's pretty clear that the anwer is that the overloading is statically bound.

dubwaia at 2007-7-13 1:49:29 >

Java programming resources: FAQs, tutorials, compiler and browser download sites, documentation, books lists, IDEs, etc.

method overloading doubt

Other Topics New Topic

Other Topics Hot Topic

Other Topics

All Classified