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.
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
Why does Java not support a nice and readable direct print-out for arrays?
I do know that Arrays.toString can be used to get that, and I also know what the hashcode output means (as explained in Why does the toString method in java not seem to work for an array).
But I am asking myself why the developers did not choose to make arrays directly print the readable representation.
Is it technically impossible? Would it impact performance?
arrays in java are a special case. There is no java source code for an array class and arrays are implemented in the JVM directly.
Given that, arrays don't have any methods themselves and they do not override any of the default Object methods (Yeah they're treated as objects but they're handled with special bytecodes).
As for why the decided to do that it probably has to do with allowing more flexibility with creating arrays of different types and dimensions, maybe processing speed as well.
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
In Java 8, the Optional class is implemented as a final container class that defines isPresent depending on the value being null. That means that it is not possible to have an Optional(null), which although not commonly used, seems like a design flaw to me. In particular, this defeats the purpose of having an optional in the first place, because you can simply set a variable to null and do the usual if (x != null), without the overhead introduced by Optional. Furthermore, the Optional class has to check if the value == null for every single operation performed on it.
In Scala however, the Option trait is much more sophisticated: It has the Some subclass for existent values and the None subclass for non-existent values. This eliminates the need for null-checks inside the class and allows Some(null) values.
My question is why the Java designers chose not to follow this subclass principle as well.
Java has empty() and ofNullable(null). Other tool methods exist too. Scala uses subclassing, case classes where other languages (still) use other notions. Scala sees typing a bit more operational.
Java Optional is workable; come with code examples. Using a Stream for an Optional might be more in the character of Scala maybe, allowing fluent design with chaining calls in a bit more comfortable way.
It lives with null and is more a recommendation as you stated.
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 8 years ago.
Improve this question
Is it considered bad practice to use a method that returns an object as a parameter? I have the following method:
public static boolean checkForBlanks(PageDescription pageDesc){
// do some stuff
}
And this method is called within another method:
checkForBlanks(aPage.getPageDescription());
Is it better practice to create a PageDescription object using the getPageDescription method first, then pass that as a parameter(The checkForBlanks methods will check a number of fields on this object) or is there any advantage to be had with the current implementation?
The PageDescription object is not used anywhere else in the calling method, so it is used explicitly in the checkForBlanks method only.
Since the instance returned by aPage.getPageDescription() is only used once within your method, there is no advantage in assigning aPage.getPageDescription() to a variable prior to passing it to checkForBlanks().
In such cases it is simply a matter of preference. I don't like the concept of tieing the hands behind the back in order to fit some misguided concept of code.
In general I prefer the idea of good looking code is good.
checkStuff(storage.getEntry()); is a easy line of good that is clear and everyone can easily follow it.
World.getSomething().doStuff(Storages.getStorage(key).getEntry()); is for example less clear to read.
Keep it clean and simple. That is the best way to go by it. If you look a week later at your code and have no clue what the heck you did, then you did something wrong.
Good code is in the end:
Have fun coding.
you should go with this (good);
checkForBlanks(aPage.getPageDescription());
instead of this (bad):
PageDescription pageDescription = aPage.getPageDescription();
checkForBlanks(pageDescription);
pageDescription in the second variant is an unnecessary local variable because there is no value read from afterwards. So you blow up your code (okay, just one line), and it will cost CPU time and Memory consumption for creating the object. Both is not needed.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I am programming something in Java and in my main-class, i have a static class variable called "file-system".
Now i want to give the variable file-system to a method from another class, which needs some information from file-system, and modifies it in some ways.
Now I am wondering: Do i have to return the new file-system from my method that is modifying it? Or is the modification taken over to my file-system in main-class due to the "static" attribute?
I don't know what else to write here, but i cannot post my question yet because editor tells me it does not serve the quality standards. Seriously, who had the idea to do a quality analyzing tool which is completely messed up and does not even let me post a single question?
If the static variable is also declared public then your other class can modify it "in place" - just reference the variable:
MyClass.fileSystem = ....
It depends on the type of your static variable. Intrinsic types (such as int, char, boolean) are copied, no matter how static it is, while for objects the reference (or a pointer if it's more clear to you) is kept.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I have been trying for a while, but now I'm wondering if I can. Is it possible for a method in an interface to return a variable or an array without needing two interfaces or methods(if possible)?
Every method has to specify a return type and stick with it. There are no "union types" like "returns a String or an int[]".
If you really have a method that can return two different things, you can
make a wrapper type (StringOrIntArray) that can hold both
or
have the method return Object which can be pretty much anything, including arrays, and use instanceof at the caller to see what you got.
Both options are not particularly attractive. Maybe take a step back and rethink the bigger picture.
What is wrong with
interface Foo{
int foo1();
//or....
int[] foo2();
}
?