Forums Register Login

java compiler issues

+Pie Number of slices to send: Send
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 java String 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??)
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 


so they designed the language to not use it.



although pointer directly refer to address so they are much faster, so in java is there any way to refer addresses directly??
+Pie Number of slices to send: Send
 

Punit Jain wrote:although pointer directly refer to address so they are much faster


Your proof of this is ... ?
+Pie Number of slices to send: Send
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..
+Pie Number of slices to send: Send
 

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.

Henry
+Pie Number of slices to send: Send
 

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.

Google for Joel Spolsky Shlemiel street painter
+Pie Number of slices to send: Send
 


Java references contain (point to) an address



you mean if i uses wrapper classes they refer to the address and if i use primitives they refer to the values isn't it??
+Pie Number of slices to send: Send
Yes, but you can’t identify the address.
+Pie Number of slices to send: Send
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??
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
well i read this while searching on google, that primitives are stored on stack and objects are on heap..
m i wrong??
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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??
+Pie Number of slices to send: Send
 

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).

Henry
+Pie Number of slices to send: Send
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??
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
. . . 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.
+Pie Number of slices to send: Send
 

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.

Henry
+Pie Number of slices to send: Send
 


With few exceptions



what type of exceptions are they??
+Pie Number of slices to send: Send
 

Punit Jain wrote:


With few exceptions



what type of exceptions are they??




Google for "escape analysis".... basically, in order to lower the need for GC, the JVM will put certain objects on the stack based on escape analysis.

Henry
+Pie Number of slices to send: Send
okay..
thank you all.....
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 


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.



Got it.
Thanks Jeff Verdegan...
+Pie Number of slices to send: Send
 

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).

Sorry about derailing the thread!

Thanks,
Praveen.
+Pie Number of slices to send: Send
 

Praveen Kumar M K wrote:

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.
+Pie Number of slices to send: Send
Thanks
+Pie Number of slices to send: Send
 

Praveen Kumar M K wrote:Thanks



You're quite welcome!
I just had the craziest dream. This tiny ad was in it.
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1477 times.
Similar Threads
newbie needs help with code
Head First Java Frustration!
why public static void main(String args[])
Add entry to PATH environment?
Generic type casting
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 12:35:29.