Printable View
Okay so I heard that java Strings are Immutable, Constants. fair enough, but that means they cannot change right?
So how come I can do this:
has mystr not being changed?? if I ran a println on mystr i know i would get the meplusonethousand output??? why is this? or do I just not get immutable lolCode:String mystr="me";
mystr="meplusonethousand";
You're confusing the object with the variable. Variables, such as mystr, can refer to different objects, but the String object itself is immutable. This is why String methods such as replaceAll don't change the underlying object that calls the method, but rather must return a new String with the changes.
but I thought that Strings were objects, that is what I find so confusing about the whole thing, they are not simple data types in java.
Are Strings ultimately pointers that just change addresses and the methods they invoke behind the scences just accomplish this or have I it all wrong again???
What is the difference between a String, and a StringBuilder I think would clarify this for me.
They are objects, and String variables are reference variables.Quote:
Originally Posted by al_Marshy_1981
Again, you're confusing String objects with the variables. The variables are reference variables which can refer to a String object, can refer to null, and can have the object they refer to changed by the assignment operator. In this they are no different from other reference variables.Quote:
Are Strings ultimately pointers that just change addresses and the methods they invoke behind the scences just accomplish this or have I it all wrong again???
A StringBuilder is a completely different object that allows you to create Strings, that is mutable.Quote:
What is the difference between a String, and a StringBuilder I think would clarify this for me.
Okay thanks for the information so far curmudgeon, I think I have a grasp what you are saying but one thing still baffles me, is the JPassword field, it comes as a char array, presumably because char arrays don't wander about in memory, but how come if a String can be set to null is it necessary to have a JPassword as a char array???
Is this not the same as changing the contents of the String variable???
e.g String password=new String(whateverCharArray);
password=null;
where is the seciurity risk after this?
I'm not sure of the answer to this. I do know that many String objects are held in the String pool so that they can be re-used, and they may remain in this pool whether or not the variable that references them is set to null, so perhaps this has something to do with this question, but I can't say for sure.
Variables, such as mystr, can refer to different objects, but the String object itself is immutable. This is why String methods such as replaceAll don't change the underlying object that calls the method, but rather must return a new String with the changes.
Okay after rereading this explanation I do understand the String class, however I do not obviously understand memory if a String variable is assigned null after being previously a confidential password and a char array which was a JPasswordField becomes Arrays.fill(""); etc. that the JPasswordField Array of chars is fundamentaly safer than a String variable??
Quote:
Originally Posted by al_Marshy_1981
If a String variable holds a password and is then set to null, the String object itself still exists until it is collected by the garbage collector, something which may take a long time and which you have little control over. So using a mutable object such as a char array that can be cleared is safer.
the String object still holds its previous assignment of the variable even though the variable has changed its contents???
Yes, absolutely. This is what we've been discussing this whole time -- Strings are immutable. Again, the variable may be made to refer to a different String object or null, but the original String object itself is immutable and does not change until it is destroyed by GC.Quote:
Originally Posted by al_Marshy_1981
I suggest that you sleep on this. I think that it will all be more clear to you if you give your brain time to mull it over. At least that's how my brain works.
Jesus was it that hard to implement a safe String? Thanks for all the replies curmudgeon. I learned a little bit more today which is always my goal :)Quote:
Originally Posted by curmudgeon
You'll have to ask the Java gods this question. I've no idea why things are made the way their made, but so far it seems to work pretty well for me.Quote:
Originally Posted by al_Marshy_1981
You're quite welcome. You seem to be asking the right questions.Quote:
Thanks for all the replies curmudgeon. I learned a little bit more today which is always my goal :)
Just one last question which has been annoying me this whole thread, why are other instances of a class called objects i.e MyClass obj = new MyClass()
and Strings (assuming they are instances which maybe they are not, since you call them variables like an int or a double) are declared like String mystr; which would seem to me reading would be like "mystr is an instance of the class String"
is the implementation just different for Strings?
No, your understanding is wrong. String is a class like any other. A variable that refers to a String object is a reference variable, just like any variable that refers to any object.
The only special treatment given to String is that the mathematical addition operators (+ and +=) can be used to concatenate Strings.
db
edit And that String literals are automatically interned in the String pool, and other Strings can be specifically interned by invoking intern()
Isn't there some web site description somewhere that explains objects and references in terms of cups? That might help, if anyone has it handy.
That's the one.
Thanks for the links, I think I understand it a bit more I'm just not 100% on the differences between how class instances and primitives types are treated by memory.
Objects live in a heap, in one of the separate spaces managed by the garbage collector. Primitives can be members of objects so they can also leave in the heap; primitives can also be local variables and are stored on the stack and finally, static final primitives can even be part of the (virtual) machine code.Quote:
Originally Posted by al_Marshy_1981
kind regards,
Jos
ps. this was an entirely different question so it belonged in its own thread.