What are the implications of Java strings not really being immutable? -

What are the implications of Java strings not really being immutable? -

background

in java 101, we're taught:

a string immutable.

yes. good. thanks.

then java 102 (or perhaps java 201), , discover:

a string isn't immutable: can alter using reflection.

ah. fine. either quite cute or immeasurably perverse, depending on perspective.

these things, far, have been discussed advertisement infinitum on stack overflow , elsewhere. taking much granted in framing question.

what i'm interested inquire this:

the question

once find string isn't immutable, implications how should write our code?

let me create more specific in 2 respects.

jvm sandboxing

is possible malicious class utilize trick break security of jvm, , tricks shouldn't? there places in jdk, instance, string returned method, , it's safe on assumption can't changed?

here's promising start:

string prop = "java.version"; // retrieve scheme property string string s = system.getproperty(prop); system.out.println(s); // mess field field = string.class.getdeclaredfield("value"); field.setaccessible(true); char[] value = (char[])field.get(s); value[0] = 'x'; //turns out we've changed not string //given underlying property too! system.out.println(system.getproperty(prop));

what retrieve scheme property jvm, comes string, , alter string; consequence underlying property changed too. can used wreak havoc?

i'm not certain. it's worth noting have have right permissions perform reflection. security game point? allows me here round not having permissions alter security properties, expected, or problem?

are there ways of extending much worse?

defensive cloning

we're told it's thought clone arrays , other objects before passing them methods might modify them, unless want them modified. it's coding practice. it's own silly fault if give re-create of array , comes messed with.

but looks though same argument ought apply string! have never, ever heard ought clone string before passing method else has written. how different, if string mutable array?

argument in favour of defensively cloning strings

if defensive cloning not knowing method might things pass it, , if we're passing mutable, ought clone it. if code might malicious, might alter string; whenever it's of import string remain unchanged, should create sure send re-create rather real thing.

it won't wash untrusted code ought run under security manager if don't trust not bad things string. if true string, true array; no 1 ever says cloning of arrays , other objects done in cases you're locking code downwards security manager.

argument against defensively cloning strings

an array might modified sloppy coding; in other words, might modified unintentionally. no 1 alters string unintentionally: can done sneaky tricks mean programmer trying break immutability.

that makes 2 cases different. shouldn't passing array, clone of it, code don't trust on level. don't download library somewhere dodgy , think you're ok because cloned array. clone defensively because think programmer might making mistakes or making different assumptions what's allowable info you're sending. if you're worried code might modifying strings behind back, shouldn't running code @ all. accomplish cloning string performance overhead.

the answer?

how should think this? can jvm sandboxing broken using these tricks? , should code defensively in lite of mutability of string, or reddish herring?

there security setting can enabled java program. according javadocs setaccessible,

first, if there security manager, checkpermission method called reflectpermission("suppressaccesschecks") permission.

a securityexception raised if flag true accessibility of object may not changed (for example, if element object constructor object class class).

a securityexception raised if object constructor object class java.lang.class, , flag true.

so, securitymanager doesn't allow check, can prevent code calling setaccessible, preserving immutability of strings.

java string security clone immutability