Wrox Programmer Forums
Go Back   Wrox Programmer Forums > Java > Java and JDK > Java Basics
|
Java Basics General beginning Java language questions that don't fit in one of the more specific forums. Please specify what version.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Java Basics section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old June 19th, 2008, 02:37 PM
Authorized User
 
Join Date: Jun 2008
Posts: 10
Thanks: 0
Thanked 0 Times in 0 Posts
Default objects and states

why make these two terms ..an object was enough!! this sounds a bit strange but if the state of an object changes ...it is a new object by itself ..right??

suppose "bill" is an instance of class "humans". now "bill at age of 5" is an entirely different object than "bill at the age of 50"....but what we are taught in the oop concepts are that bill at age 5 and 50 are 2 different states of the same object.

i feel my point of argument to be stronger ...but am just a noooob to say so.
i would want some expert comments ..please !!
 
Old June 19th, 2008, 04:28 PM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

Not necessarily.

You *CAN* make "immutable objects". java.lang.String is an immutable class, for example. Once you create a String object, its value can never change.

But then contrast it with java.lang.StringBuffer, which not only can change but is expected to change.

So, yes, I could create a Person class either way: mutable or immutable. If I create it immutable, then indeed "bill age 50" will not be the same object as "bill age 5". But if I make it mutable, and make age just a property of the class, then sure I can change "bill age 5" to make the object "bill age 50". They really *ARE* the same object, just at different states in its life cycle. The two ages can't coexist at the same time, of course. It's all in the design of your class.
 
Old June 20th, 2008, 01:10 AM
Authorized User
 
Join Date: Jun 2008
Posts: 10
Thanks: 0
Thanked 0 Times in 0 Posts
Default

thanks a lot for replying !!
i was indeed being a bit philosophical :)
i got the concept of immutable objects...but i dont have a real picture of how the mutable objects are "transformed within the same memory location". hope you will help again
 
Old June 20th, 2008, 07:13 PM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

Do you understand compilers? Do you understand assembly/machine level programming??

Oh, what the heck.

class Person
{
    public String name;
    public int age;
}

And now we do, say,
    Person joe = new Person( ); // line 1
    joe.name = "Joseph"; // line 2
    joe.age = 5; // line 3

What *actually* happens?

line 1: Java allocates 12 bytes of memory for a "Person" object. 4 bytes are overhead [actually, this number is very much Java runtime dependent], 4 are a *REFERENCE* to the string, and 4 are the actual memory that will hold an integer age.

line 2: "Joseph" is a constant string, so it was already created and stored in memory during the compilation/initialization phases. So all that *really* happens here is that the memory address of that string is stored in the 4 bytes reserved for "name" within those 12 bytes.

line 3: The binary representation of the integer 5 is stored in the 4 bytes reserved for "age" within those 12 bytes. (If you care, the actual bits will be
    00000000 00000000 00000000 00000101
but you really shouldn't care about that.)

Okay, so NOW what happens when we do
    joe.name = joe.name + " Smith"; // line 4
    joe.age = 55; // line 5
??

line 4: Recall that strings are immutable. So in order to concatenate the two strings "Joseph" and " Smith", java builds a *NEW* string with a length that is the sum of the lengths of the two originating strings. Then it copies the characters of the first string in to that new string followed by the characters of the second string. In essence, it creates a BRAND NEW STRING with the contents
    "Joseph Smith"
And then it puts the address of *THAT* string into the 4 bytes in memory that formerly held the address of the "Joseph" string. Note the important point here: EVEN THOUGH THE Strings are immutable, and even though the *new* "Joseph Smith" string is immutable, the Person object has no problem changing its "pointer" (called an "object reference" in Java parlance) to point to another value!!

line 5: The binary representation of the integer 55 is put into the 4 bytes that used to hold the binary representation of 5. Note that this truly is a complete replacement. And note that the int value *IS* mutable! (All "primitive types" are mutable by default; only if you wrap other code around them that tells the compiler they can't be changed do they acquire any immutable characteristics.)

So there you have it: The variable named "joe" in your program never *DID* hold an actual Person object. It always simply had a pointer (object reference) to the 12 bytes of memory that was allocated via the new operator. And whether those 12 bytes of memory are mutable or immutable is strictly a compiler capability. If memory can be written once (e.g., when the object was created) it can clearly be written into again. So the immutable aspect of an object only occurs because of restrictions that you, as a programmer, put on it, courtesy of the capabilities of the compiler.

*************

This has been kind of rambling and not well-prepared, but I hope you get the idea. If not, it might be worth reading a little bit of compiler implentation theory, just to get some of the concepts.
 
Old June 21st, 2008, 05:54 AM
Authorized User
 
Join Date: Jun 2008
Posts: 10
Thanks: 0
Thanked 0 Times in 0 Posts
Default

thanks ..thanks a lot for taking out your precious time and such a nice explanation. you rock !!

just one of the lines i failed to understand perfectly even after re-re-reading your post :
 "And whether those 12 bytes of memory are mutable or immutable is strictly a compiler capability."
 
Old June 21st, 2008, 03:23 PM
Friend of Wrox
 
Join Date: Jun 2008
Posts: 1,649
Thanks: 3
Thanked 141 Times in 140 Posts
Default

[i]just one of the lines i failed to understand perfectly even after re-re-reading your post :
 "And whether those 12 bytes of memory are mutable or immutable is strictly a compiler capability."[i]

Well, I dunno how to say it more clearly. At the machine level, the 12 bytes of memory that are used to hold one instance of the Person class (that is, they hold one Person "object") are *always* writable. [With some very odd exceptions that don't apply to PCs.]

So whether the *program* treats them as writable or not is completely up to the language you are using and therefore up to the compiler that produces the code that is (or is not) capable of changing the locations.

I noted that all primitive types are, by default, mutable. But consider this: At the machine level, *ALL* data is primitive! So even the contents of a String are actually an range of bytes in memory that are definitely mutable...except the the C#/VB.NET/C++/Java compiler simply won't produce machine code that *will* alter them. So... It's up to the compiler, as I said.
 
Old June 22nd, 2008, 02:57 AM
Authorized User
 
Join Date: Jun 2008
Posts: 10
Thanks: 0
Thanked 0 Times in 0 Posts
Default

thanks a lot !!:)
this really helped me !!
 
Old June 26th, 2008, 03:26 AM
jomet
Guest
 
Posts: n/a
Default

Old Pedant post is helpfull to me also.
Thanks for your nice explanation.



jomet.
`````````````````````````````````````````````````` ``````````````````````
Once you start a working on something, dont be afraid of failure and dont abandon it.
People who work sincerely are the happiest.





Similar Threads
Thread Thread Starter Forum Replies Last Post
Dgrid control states in DataGrid dungerdanish General .NET 0 March 28th, 2005 06:42 AM
United States Daylight Savings Time mega Forum and Wrox.com Feedback 4 August 24th, 2004 08:03 AM
Session States, Global. asax and web.config ohmbhu General .NET 2 July 1st, 2004 09:15 AM
Persistence of control states between posts pankaj_daga ASP.NET 1.0 and 1.1 Basics 1 November 20th, 2003 08:11 AM
Trouble with session states wigmo BOOK: Beginning ASP.NET 1.0 2 October 28th, 2003 09:46 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.