Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Unnecessary cast in List?

 
Burkhard Hassel
Ranch Hand
Posts: 1274
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi ranchers,

this is not from a mock exam, but perhaps you like it as a little brain teaser for in between.
The question is about collections. Java 5 only.

having

Question: isn't the cast to Integer unnecessary?
And what are the three output lines?
Does it compile anyway?


Yours,
Bu.
 
Abdul Rehman
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It compiles fine, atleast in my assessment!

The cast is compulsory, because, without it, the compiler will take the "3" as argument of type int, removing an item from the index 3. By putting the cast, we make sure that a call is made to remove(Integer), which will remove the item i.e. Integer object [3] and not the item at index 3.

Predicting the output is a little hard, as one has to take out some old memories from the mind's cupboard, about the return-type of remove(...). If I am correct, the output should be:

4
true
[1, 2, 5]


or if the above is wrong, it may be:

4
3
[1, 2, 5]

Best regards,
Abdul Rehman.
 
Abdul Rehman
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The following extracts from the JLS, Section 15.12.2 would further elaborate my previous post:-

--------------------------------------------------------

A method is applicable if it is either applicable by subtyping (�15.12.2.2), applicable by method invocation conversion (�15.12.2.3), or it is an applicable variable arity method (�15.12.2.4).

...

Discussion
The purpose of the division into phases is to ensure compatibility with older versions of the Java programming language.

The first phase (�15.12.2.2) performs overload resolution without permitting boxing or unboxing conversion, or the use of variable arity method invocation. If no applicable method is found during this phase then processing continues to the second phase.

Discussion
This guarantees that any calls that were valid in older versions of the language are not considered ambiguous as a result of the introduction of variable arity methods, implicit boxing and/or unboxing.

The second phase (�15.12.2.3) performs overload resolution while allowing boxing and unboxing, but still precludes the use of variable arity method invocation. If no applicable method is found during this phase then processing continues to the third phase.

Discussion
This ensures that a variable arity method is never invoked if an applicable fixed arity method exists.

The third phase (�15.12.2.4) allows overloading to be combined with variable arity methods, boxing and unboxing.

--------------------------------------------------------

Regards,
Abdul Rehman.
[ November 23, 2006: Message edited by: Abdul Rehman ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic