• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

what is int... refer to?

 
sri narayanan
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,

when i was going through the SCJP 5 by kathy ,sierra.i came across the term

static void doStuff(int... args){}

page number:79

please clarify what does that "int..." refer to ?

thanks in advance
sriram
 
pascal betz
Ranch Hand
Posts: 547
 
Adam Nace
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The elipses (...) is used to indicate varargs, a new feature of Java 1.5.

All it REALLY means is that the variable args is an array. So it could have just as easily have been defined as:



Basically, the difference in notation is just to help the readability of the code. When you see the parameter declared as an array, it typically implies that there is some sort of logical similarity of all the items in the array, whereas when you see it defined with the elipses, each of the elements typically represents some completely different parameter of the method.

There is, a syntactic difference with the actual parameters passed as well. With the introduction of varargs, instead of passing an array as the last argument, you can pass a comma separated list of objects instead.

i.e.


Personally, I think that varargs are terrible. They introduce a lot of ambiguity to method signatures, making it more difficult to predict which overloaded version of a method will be called (this is specified by the jls, but it is still confusing). Generally, if you're going to use varargs, you should avoid overloading the method. Also, varargs prevents type safety, moving java further away from being a strongly typed language, which I think is a bad thing. For instance, if instead of int, you used Object, then a user could technically send you an array of any size of any type of object they wish to send. So you really don't know what you're going to get. I fail to see how this is a good thing, and I strongly encourage everybody to avoid varargs in most cases. The code required to make a varargs method safe, and do the logic required to deal with the fact that the arguments are variable is often more complicated and confusing then if you simply write a couple of overloaded methods to handle the different expected sets of parameters.

One good stylistic use of var args might be in statistics, when you want to create functions to evaluate properties of a small sample set.

e.g.



Hope this helps!

- Adam
 
sri narayanan
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi pascal and adam ,

thanks for your sincere reply.

adam thanks for your detailed explanation.

bye
sriram
 
Campbell Ritchie
Sheriff
Pie
Posts: 49812
69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
. . . so I thought I would try it out.Try it. See what happens.
Change the second statement in the go() method to read 1, 2, 3 rather than 1, 2, 3, 4.
Then see what happens. CR
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15441
41
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Adam Nace:
[QB]Personally, I think that varargs are terrible. They introduce a lot of ambiguity to method signatures, making it more difficult ...

The Java language designers already warn you about all of this on the page that explains varargs in the JDK 5.0 documentation:
So when should you use varargs? As a client, you should take advantage of them whenever the API offers them. Important uses in core APIs include reflection, message formatting, and the new printf facility. As an API designer, you should use them sparingly, only when the benefit is truly compelling. Generally speaking, you should not overload a varargs method, or it will be difficult for programmers to figure out which overloading gets called.

Varargs was probably only included in the Java API to support printf(...), which is something that came from the C programming language.
 
Ken Blair
Ranch Hand
Posts: 1078
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well if they warn you about it then it must be okay! I agree with Adam and furthermore for similar yet even more heinous reasons I think autoboxing is terrible too. Both of these "features" introduced added complexity and ambiguity to what is supposed to be a simple language. Neither of these features allow you to do anything you couldn't do before, they simply hide it behind syntactic sugar. Syntactic sugar can be nice, but not at this cost and not for such marginal returns, but that's just my opinion.
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15441
41
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ken Blair:
Well if they warn you about it then it must be okay!

That's not what I said or meant.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic