> This is true for custom classes. For primitive types such as int.class, void.class and Object itself have no super class.
This is misleading. Primitives (and void) are not classes at all, which is why they do not have a superclass. Interfaces also don't have superclasses for the same reason. These all do have a representation of the type 'java.lang.Class', and they all support the class literal (X.class) expression, but they are not classes. java.lang.Object is still the base class for all classes.
If I had an interviewee throw this stuff at me, I'd consider it a negative. If you're going to be pedantic, you'd better be correct.
As for this:
> Which one is faster in Java ?
> for(int i = 100000; i > 0; i--) {}
> for(int i = 1; i < 100001; i++) {}
> Answer: Which ever is run second with be fastest. The server JVM can detect and eliminate loops which don't do anything...
Will the compiler itself not detect and eliminate these?
Edit: Apparently no, the compiler won't optimize those away. I can't imagine why. Whether the JIT will optimize away the second loop isn't as clear as he indicates, though. Assuming they are in separate methods, optimizing the first away (after it runs) will have no effect on the second.
A Class is a proxy for the underlying representation of the type/class. IMHO, int.class is just as much a Class as Integer.class.
The compiler does next to no optimisations and the "client" JIT doesn't remove loops which don't do anything. Only the "server" JIT eliminates such loops, after it has compiled the method which can be triggered by loop which loops many times.
> A Class is a proxy for the underlying representation of the type/class. IMHO, int.class is just as much a Class as Integer.class.
There are two separate things here: Class and class. Capital-C "Class" is a proxy for a type. Small-c "class" is a kind of type in Java. When someone asks why 'int' does not have a super class, the answer is because 'int' is not a class. It does have a corresponding Class* (which might have been more appropriated named "Type"), though. (There's also the '.class' literal which yields a Class. Again, the naming could have been better.)
* The Class returned by int.class actually does have a super class, because Class is a class. e.g.: int.class.getClass().getSuperclass() yields a Class representing Object.
Everything in Java is passed by value, as is the case in, for example, C[1] and Ruby. That the value that is passed is also called a reference does not change the fact that it is not call-by-reference.
There is a simple way to check whether a language does call-by-reference: can you write a swap function such that after calling swap(a, b), the variables a and b in the calling function refer to different values than before? In Java this is impossible.
Because the terminology is so confusing when object reference values are being passed-by-value, Barbara Liskov suggested we call it call-by-sharing.
[1] you can make C look like it's doing pass-by-reference by throwing some & and * operators around. That doesn't change the fact that it is purely call-by-value.
I believe any object passed in Java can be modifed by the receiving method, right? So that is pass-by-reference. If we want to say we're really passing a reference by value, that begins to be silly - if the object passed can be modified, its a reference.
It's a technicality. You always get a copy of what you pass in. When you pass a primitive, eg an int that has the value 7, you get a copy of that value 7. When you pass an object, you get a copy of the reference to that object.
You understood correctly, it's just how it gets phrased.
That's true. I think this article is being a bit pedantic on this point.
You can never have a variable that directly represents an object in Java. You can only ever hold a reference to an object. Those references to objects are passed by value.
So his statement is more technically correct, but in general "objects are passed by reference and scalars by value" is the understanding that an interviewer would likely be looking for.
The distinction between “pass by reference” and “pass by value” started with Algol, if I recall correctly, and made sense in that language, where you can declare which arguments of your function are passed in which way. It also makes sense in C++, which has a similar feature.
For other languages, I think framing parameter-passing in these terms just creates more confusion then it resolves. I would rather describe the situation like this: In Java, when you pass a mutable object (or array) to a method and the callee mutates it, the caller will see the changed version.
A pedantic interviewer won't tell you if mix your terminology incorrectly. The more experience you have, the more pedantic you tend to get because computers are pedantic. They do exactly what you tell them to, not what you meant it to do. ;)
> java.lang.Object
> This is true for custom classes. For primitive types such as int.class, void.class and Object itself have no super class.
This is misleading. Primitives (and void) are not classes at all, which is why they do not have a superclass. Interfaces also don't have superclasses for the same reason. These all do have a representation of the type 'java.lang.Class', and they all support the class literal (X.class) expression, but they are not classes. java.lang.Object is still the base class for all classes.
If I had an interviewee throw this stuff at me, I'd consider it a negative. If you're going to be pedantic, you'd better be correct.
As for this:
> Which one is faster in Java ?
> for(int i = 100000; i > 0; i--) {}
> for(int i = 1; i < 100001; i++) {}
> Answer: Which ever is run second with be fastest. The server JVM can detect and eliminate loops which don't do anything...
Will the compiler itself not detect and eliminate these?
Edit: Apparently no, the compiler won't optimize those away. I can't imagine why. Whether the JIT will optimize away the second loop isn't as clear as he indicates, though. Assuming they are in separate methods, optimizing the first away (after it runs) will have no effect on the second.