Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
i know method
signature use parameter,
and method use arguments when method call.
so i don't know why java main method parameter name 'args' is not 'param'
I am sorry that I am not good at English.
Just a variable name, you can use any name that meets the Java variable naming requirements
You can use any name for that, but "args" is short for "arguments". Some people prefer "parameter", some "argument". See also: "Parameter" vs "Argument"
It's not a matter of choice, it's about the meaning of the words: an argument is not a parameter
main(String args)
args is the method argument
main(null)
null is the parameter by which the method is invoked
See https://stackoverflow.com/a/1788926/1575188
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm working on a project where we have a method like this:
processEvent(event, context) {
// var result = some processing here
context.setResult(result);
// context's class have nothing to do with processEvent's class
return context;
}
The class SomeClass containing processEvent method has no inheritance relation with context's class (so it's not about a builder pattern here). For me, the context returning is silly because the direct caller would already have it. Are any other more plausible arguments in favor of or against this approach?
It's not uncommon to have a method return one of its parameters' values if it doesn't have any other return value. It enables code like this:
Context context = processEvent(event, new Context(/*...*/));
Whether that's good or bad style is, er, a matter of style. :-) It's not all that common, but I wouldn't say it's uncommon, either.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I recently took an online test for an interview. It was a multiple choice test and I got the following question:
Q) In a Java class we can write multiple methods with same name and
different method signatures, this is called_____________
a) function overriding
b) function overloading
c) none of the above
I know that it is method overloading but in the options it's not there
Is the term function overloading equivalent to method overloading in Java?
From a pragmatic point of view, I would go with function overloading.
But when thinking in pure Java terms, the one and only term is methods. Java does not know functions, only methods. Besides the interface Function.
Coming from there, it is not really clear if "none" or "function overloading" is the correct answer.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm struggling with a naming issue. What name would you give to an interface that have just one method with this signature:
public interface ?
{
boolean isAvailable();
}
Many classes in my application can implement this interface.
Not that it really matters, you can rename it any time afterwards, and with current IDEs, it is really easy to type any name using autocomplete...
That said, if you want it short, use Available, if you want it more self-explanatory, use CanBeAvailable.
Given that the word "available" already ends with "-able", I think it's okay to break with the Java interface naming convention and call it Availability. Another approach, suggested in Programmers, is to use the prefix "Can-", in which case you can call your interface CanBeAvailable.
The below are the standards defined for Naming conventions.
Class - Always be a Noun
Interface - Always be an Adjective
Method - should be a verb
So, think of some adjective which describes the purpose of your interface.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Given the following method of a class which doesn't have type T defined:
public <T> T get(java.lang.String name) { /* compiled code */ }
Would it be possible to invoke this, and how?
Yes. Just call it with an explicit type argument:
foo.<Integer>get("something")
I'm not terribly fond of how type arguments are expressed in Java, but they're perfectly doable. See the Java Generics Tutorial for another example.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am well aware that the void keyword is used to indicate in a method declaration that the method will return no value. My question is not about - to use an analogy - how to use the car, but rather about what's underneath the hood. I would like to know why void actually needs to be specified, i.e. does Java reserve an internal variable of some sort to keep track of return types? Will setting a method to void make it so that it doesn't have to do this?
Another way to put it is to ask why, exactly, can't Java omit the void keyword and assume that if there is no returned type than the method is void? I think that there is something to do with how Java might "prepare" to handle the return type, and possibly something to do with optimization... please use full detail.
Its a java language Specification
void used with only methods declaration
if we omit void then its treated as constructor.
SEE THIS
my answer is a bit of a guess. But I'd say its to protect the developer against just forgetting to declare the return type. Sure the compiler can even by default be programmed to render undeclared return types void. But that would be at cost to the aid for the developer.
Furthermore, IDEs would have to anticipate on the same.