i just started reading "Thinking in java" writen by "bruce eckel"
sach a nice book..
as i read in that book javac uses operator overloading, In case of javaString classes.
and also i know that javac also uses pointers to refer objects of any class (plese correct me if i m wrong).
so what i think is that java also uses all features of c++, but java compiler, not available for programmers, isn't it??
also i need to know onw thing, why main takes array argument of string type, wheather it is used to take command line user input, but why it's always required in the main, doesn't matter we are taking any command line input or not (i only know that it's always be there(in main), but don't know why??)
As I understand it, the designers of the language wanted to write something similar to C to allow for an easier transition. However, pointers in C caused no end of bugs. They believed that the headaches were not worth the benefit, so they designed the language to not use it.
Now, the java compiler was (I believe) originally written in C, which means it could use pointers. I don't know if it does or not.
When you type "java <classname>", the JVM is designed to look for the specific method with the signature of "public static void main (String [])". That's where the program starts. The main method is just like any other method - you can overload it and write a method like "public static void main()", but the JVM won't call it at startup.
well, if i point to any value, than it will go to that address, but if i point directly to the address, it has no need to go to address so it makes faster, i believe.
please correct me if i m wrong..
Punit Jain wrote:well, if i point to any value, than it will go to that address, but if i point directly to the address, it has no need to go to address so it makes faster, i believe.
please correct me if i m wrong..
huh? Not sure what you are trying to say.
BTW... Java references contain (point to) an address. And for many intents and purposes, behave just like a C/C++ pointer. What you can't do with a java reference, is pointer arithmetic -- which doesn't happen when you are just dereferencing (ie. accessing) to get a value.
Punit Jain wrote:. . . pointer directly refer to address so they are much faster, . . .
C uses null-terminated Strings, so access to the ith character takes linear complexity. Java™ uses array-based Strings, so access to the ith character runs in constant time.
okay but although wrappers refer to address, but also they stored in heap, whereas primitives stored in stack, so accessing primitives is faster, i think, but again wrappers refer to address so they should be faster??
What makes you think primitives are stored on the stack? What makes you think finding something on the stack, except its top element, is faster than finding something on the heap?
Not always. The idea is not to look at where the objects/variables/references are stored but as to how long once can use them(scope). The storage is completely up to the memory management layer.
Likewise contrary to popular belief(its REALLY popular!), static variables are not stored on the stack! They are stored in the static part of the memory, which might be stack or heap or whatever other memory that's available at runtime.
yes static variables are stored are in static storage (somewhere in memory), but how to know where my variable is stored in stack or heap, and what to do if i want to explicitly stored a variable on stack or heap??
Punit Jain wrote:okay but although wrappers refer to address, but also they stored in heap, whereas primitives stored in stack, so accessing primitives is faster, i think, but again wrappers refer to address so they should be faster??
I think the issue is being overly complicated (or incorrectly complicated) here. This isn't a references versus pointer issue. This isn't a stack versus heap issue.
At best, you can say that primatives may be faster because it doesn't have to be dereferenced.... but even then, there are tons of optimization going on, and it is in the realm of nanoseconds (which is difficult to even see the difference).
You should beware of simply googling; people can post misinformation, or simply be mistaken themselves.
With few exceptions, objects live on the heap. Many primitives are fields of objects, so they live inside the objects on the heap.
Local variables and method arguments usually live on the stack; these might be primitives, in which case their actual value is stored there, or reference types, in which case the reference to their memory location is passed.
. . . at least I think that is correct.
No, you do not have direct access to anything on the heap. Only to its references hidden behind identifiers. If you lose access to a reference you cannot retrieve it, and it is eligible for garbage collection.
Campbell Ritchie wrote:You should beware of simply googling; people can post misinformation, or simply be mistaken themselves.
With few exceptions, objects live on the heap. Many primitives are fields of objects, so they live inside the objects on the heap.
Local variables and method arguments usually live on the stack; these might be primitives, in which case their actual value is stored there, or reference types, in which case the reference to their memory location is passed.
Also, in certain cases (ie. compile time constants), the "variable" may not live anywhere at all. If the compiler deems a variable as a compile time constant, it's value will simply be used when it is needed. No memory, stack or heap, is allocated to hold the value.
Punit Jain wrote:okay...but it creates a question in my mind??
where primitives are stored and where objects actually??
and do we have direct access to them??
Up to Java 6, all local variables are stored on the stack (both local primitives and local reference variables) and all objects are stored on the heap (including all member variables--static, non-static, primitive, and reference). Simple and tidy.
Starting in 6 or 7, there was talk of allowing escape analysis, so that JVM implementations could choose to store an object on the stack if it could be sure that the object was never referenced outside that invocation of that method. I don't know if that made it into the spec, or if it is implemented in any JVMs, but if it is, it's just a slight modification to the initial rules: All local variables are still on the stack, and most objects are still on the heap, but some short-lived objects may be on the stack, though we probably wouldn't in general be able to predict which ones.
All local variables are still on the stack, and most objects are still on the heap, but some short-lived objects may be on the stack, though we probably wouldn't in general be able to predict which ones.
Jeff Verdegan wrote:Up to Java 6...all objects are stored on the heap (including all member variables--static, non-static, primitive, and reference). Simple and tidy.
Need a little clarification here. When you refer to static member variables, you mean that these static variables are stored in the Class object of that class right? And not one copy in each instance(all having same value).
Jeff Verdegan wrote:Up to Java 6...all objects are stored on the heap (including all member variables--static, non-static, primitive, and reference). Simple and tidy.
Need a little clarification here. When you refer to static member variables, you mean that these static variables are stored in the Class object of that class right?
Yes. And class definitions are stored in the method area, which, according to the JVM spec, is "logically part of the heap." So, it's the heap area/structure in memory (in contrast to the stack), but no, it's not duplicated for each instance.