aspose file tools*
The moose likes Beginning Java and the fly likes java compiler issues Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "java compiler issues" Watch "java compiler issues" New topic
Author

java compiler issues

Punit Jain
Ranch Hand

Joined: Aug 20, 2011
Posts: 998
    
    2
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??)
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11239
    
  16

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.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Punit Jain
Ranch Hand

Joined: Aug 20, 2011
Posts: 998
    
    2

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??
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61043
    
  66

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

Your proof of this is ... ?

[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Punit Jain
Ranch Hand

Joined: Aug 20, 2011
Posts: 998
    
    2
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..
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18743
    
  40

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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38392
    
  23
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

Joined: Aug 20, 2011
Posts: 998
    
    2

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
Sheriff

Joined: Oct 13, 2005
Posts: 38392
    
  23
Yes, but you can’t identify the address.
Punit Jain
Ranch Hand

Joined: Aug 20, 2011
Posts: 998
    
    2
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
Sheriff

Joined: Oct 13, 2005
Posts: 38392
    
  23
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

Joined: Aug 20, 2011
Posts: 998
    
    2
well i read this while searching on google, that primitives are stored on stack and objects are on heap..
m i wrong??
Praveen Kumar M K
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
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

Joined: Aug 20, 2011
Posts: 998
    
    2
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
Sheriff

Joined: Sep 28, 2004
Posts: 18743
    
  40

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

Joined: Aug 20, 2011
Posts: 998
    
    2
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
Sheriff

Joined: Oct 13, 2005
Posts: 38392
    
  23
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
Sheriff

Joined: Oct 13, 2005
Posts: 38392
    
  23
. . . 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
Sheriff

Joined: Sep 28, 2004
Posts: 18743
    
  40

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

Joined: Aug 20, 2011
Posts: 998
    
    2

With few exceptions


what type of exceptions are they??
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18743
    
  40

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

Joined: Aug 20, 2011
Posts: 998
    
    2
okay..
thank you all.....
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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

Joined: Aug 20, 2011
Posts: 998
    
    2

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

Joined: Jul 03, 2011
Posts: 256
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

Joined: Jan 03, 2004
Posts: 6109
    
    6

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

Joined: Jul 03, 2011
Posts: 256
Thanks
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Praveen Kumar M K wrote:Thanks


You're quite welcome!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: java compiler issues