How old is the Venners book?
Campbell Ritchie wrote:Or the Java™ Virtual Machine Specification. It's by no means easy to read, however.
How old is the Venners book?
Pretty old Java 2 version. But it gets reprinted with the same stuff. I have a latest reprint but of Java2- Most of the basic architecture is explained in that. I was actually looking for one book and couldnt get much information regarding the books available for JVM internals.
I think I need to check out the JVM Specs.
Campbell Ritchie wrote:You can download the JVM Spec free of charge, so you haven't lost anything if you don't like it
Actually, agree with you. I was also thinking of a hardcopy of the book so bought Inside JVM. I will be downloading the specs as well. Again I fail to make it past one chapter- Its kind of lack of motivation to read through the book. May be some tips to study through would be useful
Thanks for the replies; What i really meant was Design decisions taken when developing java language. like whys is main method marked static.
Why java supports only Pass By value. Life cycle of an object and so on.
well the book internals of JVM looks not great book as a read the amason reviews.
I'll start but these are just my guesses. I've read what I can find but make no claim for knowing what the designers were thinking.
I don't think Java is strictly call by value only, but it may be semantics, a call by reference in my mind is being performed with objects in the sense we can return values that way. I believe the lack of pointers and thus no C/C++ type call by reference is because of garbage collection and automatic deallocation. In order for everything (or almost everything) to be movable the VM is the only thing that knows where they really are.
As to why main is static, what's the alternative? The VM could instantiate the main class and call a non static main method but I don't see an advantage. If that's what you want to do the static main method can do it in one or two lines of code and then keeping track of the object is the applications responsibility. If the main class constructor is private it's a good way to ensure only one main object gets created. I think that's how the Swing Framework does it.
Again, I put up my opinion to start a discussion, I don't claim any inside knowledge or even that I know my elbow from a hole in the ground, let alone that I'm right.
Campbell Ritchie wrote:Java™ is most definitely call-by-value; if it were call-by-reference, it would be possible to alter the value of the reference passed as an argument, but it isn't.
I should have been more precise. Yes, Java is definitely call by value but that value is not always a newly allocated copy of the object in question. For example:
Here what is being passed is a (different kind of )reference to the String array, there is only one array in memory.
I guess what I'm trying to say is that a method call can return more than one value. Of course, if you passed a String instead of a String array you'd get a copy.
- X 2
I would like to understand the laws of India.
For example I would like to know why red means "Stop" and green means "Go" in a traffic light.
In this case I am not sure that studying the laws of India would tell you anything about why traffic lights are the way they are. Likewise I'm not sure that studying the internal operations of Java virtual machines would tell you anything about why the JVMs were designed the way they were.
Thanks for the replies.
Yes you'r right. I wanted to know why these decisions where taken. studying JVM internals will tell in more details how things are working at compile time and at runtime
I'll get more info on how but not on why. Was curious in understanding the design decisions itself.
There is something that can be said about this. In the mid-1990s, C++ was the big language that everybody was looking at. (I was a C++ guru myself before I started programming in Java). But C++ is not an easy language, it has a number of pitfalls that make it easy to make wrong programs and it's very hard to understand all the little nuances and potential problems.
The designers of Java wanted to create a language that would look familiar to C++ programmers, but that would be easier to learn and use. So they left out many things that cause a lot of trouble in C++, such as pointers, manual memory management, virtual member functions, pass by reference, multiple inheritance etc. As a result people can learn Java faster and be more productive with Java than with C++.
To take pass by reference as an example: the Java language designers probably thought that this is a feature which is not really necessary, it probably causes more trouble than it's worth, so to keep the language simple they just didn't include it in Java. (You can imagine what bugs might arise when people accidentally would pass something by reference, etc.).
There are books like Java The Good Parts, by Jim Waldo, that explain some elements of the language from the perspective of a well-known and influential contributor. Well, sort of, anyway. That particular book is a bit ponderous and pompous to read and not as informative on the nuts and bolts as you might hope. But that's usually where the 'why' comes from, individual contributors willing to write about their experience participating in the process.