• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

java compiler issues

 
Ranch Hand
Posts: 1143
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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??)
 
lowercase baba
Posts: 13089
67
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Punit Jain
Ranch Hand
Posts: 1143
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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??
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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


Your proof of this is ... ?
 
Punit Jain
Ranch Hand
Posts: 1143
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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..
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Punit Jain
Ranch Hand
Posts: 1143
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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??
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, but you can’t identify the address.
 
Punit Jain
Ranch Hand
Posts: 1143
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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??
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Punit Jain
Ranch Hand
Posts: 1143
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well i read this while searching on google, that primitives are stored on stack and objects are on heap..
m i wrong??
 
Ranch Hand
Posts: 256
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Punit Jain
Ranch Hand
Posts: 1143
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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??
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Punit Jain
Ranch Hand
Posts: 1143
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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??
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Campbell Ritchie
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
. . . 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.
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Punit Jain
Ranch Hand
Posts: 1143
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


With few exceptions



what type of exceptions are they??
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Punit Jain
Ranch Hand
Posts: 1143
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
okay..
thank you all.....
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Punit Jain
Ranch Hand
Posts: 1143
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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...
 
Praveen Kumar M K
Ranch Hand
Posts: 256
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Praveen Kumar M K
Ranch Hand
Posts: 256
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Praveen Kumar M K wrote:Thanks



You're quite welcome!
 
reply
    Bookmark Topic Watch Topic
  • New Topic