Books on internals of Java

[Chandra shekar M]

Hi,

I have done my SCJP 1.5 98% and SCWCD 1.5 96% now i want to understand internals of Java.

How actually concepts r implemented. Can anybody tell some good books for the same?

ex:
I am looking for the below answers
why java is only pass by value, Why main method is marked as static ...

Thanks

[Mohamed Sanaulla]

By internals if you mean- JVM Concepts- Inside the JVM by Bill Venners is a good book.

[Campbell Ritchie]

Or the Java™ Virtual Machine Specification. It's by no means easy to read, however.

How old is the Venners book?

[Mohamed Sanaulla]

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]

You can download the JVM Spec free of charge, so you haven't lost anything if you don't like it

[Mohamed Sanaulla]

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

[Chandra shekar M]

Hi All,

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.

Please suggest.

Thanks
Chandrashekar

[Chandra shekar M]

Hi All,

Any updates on this.

Thanks
Chandra

[Joe Areeda]

These seem good topics for discussion. I've found it difficult to get definitive answers to why something was designed one way or another unless the designer's write about it.

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.

Joe

[Campbell Ritchie]

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.

[Joe Areeda]

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:

    public static void main(String[] args)
    {
        String[] str = {"original"};
        modifyIt(str);
        System.out.println(str[0]);
    }

    private static void modifyIt(String[] str)
    {
        str[0] = "modified";
    }

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.

Joe

[Michael Ernest]

What you're doing here is passing a reference that contains another reference, then changing the value of the indirect reference. Try passing the array element, not the array.

[Paul Clapham]

Chandra, are you sure you really want to study the internals of Java? To me your question seems rather like this:

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.

[Campbell Ritchie]

Another way to understand what Michael Ernest says is that you are passing the value of an object which can be manipulated. You cannot change the array's reference, but you can manipulate it. You can change the state of the array, but it is still the same array. A bit like passing the value of a reference to foo

public void foo(Foo foo)
{
   foo.setFoo(123);
}

That is a pretty useless method, but what it does is to alter the state of the object referred to by the variable foo. That isn't pass-by-reference, but receiving the value of a reference to a mutable object.

[Joe Areeda]

I do understand the difference between a call by reference and a call by value passing a reference to a mutable object.

I guess, I can not express it in a clear way. I did not mean to start a debate on the meaning of call by reference. Sorry.

[Chandra shekar M]

Hi All,

Thanks for the replies.

Paul,

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.

Thanks
Chandra

[Jesper de Jong]

It's hard to say why some things in Java are the way they are. The designers of the language had some idea in their heads of how Java should be, and that's how they implemented it. But I don't know of any book where the original language designers explain all their reasons for designing it as it is.

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

[Michael Ernest]

It's also worth remembering that some elements of the language are entered for reasons other than best-of-breed technical decisions, and that's a very good thing. Some design decisions are made by fiat, others by varying degrees of consensus. Still other features may represent the pet interest of some contributors that no one else is interested in arguing over.

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.