This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Java in General and the fly likes Not so Immutable Strings Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Not so Immutable Strings" Watch "Not so Immutable Strings" New topic
Author

Not so Immutable Strings

Garrett OBrien
Greenhorn

Joined: Oct 25, 2005
Posts: 8
I have written a completely useless program that changes a String, and I was wondering if it will work on other JVMs. I know that by accessing private variables, I'm asking for problems and I really shouldn't be doing it, but that's never stopped me before. I was just curious if the implementation of String is the same (or similar) across platforms/JVMs.

Thanks

Garrett


import java.lang.reflect.Field;

public class Empty
{
public static void main(String[] args)
{
System.out.println("");
}
static
{
long l = 0x20AC63C177C984l;
String s = "!";
while(l!=0)
{
s=(char)(l%32+((l%32!=0)?64:32))+s;
l/=32;
}
try
{
Field value = String.class.getDeclaredField("value");
Field count = String.class.getDeclaredField("count");
value.setAccessible(true);
count.setAccessible(true);
count.set("", new Integer(s.length()));
value.set("", s.toCharArray());
} catch (Exception e)
{
// don't care if there is an error
}
}
}
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Hi,

Welcome to JavaRanch!

Yes, I expect you'd be able to do something like this on essentially all JVMs. Java's security model, by default, allows this sort of backstage shenanigans in local applications, mostly because if someone has access to run a local application, they already can compromise the machine. For example, there's nothing to stop you from adding your own String.class to the boot classpath which offered mutability as part of its public API.

But that's for local applications. Try the same thing in a Web applet, or in many other situations where a SecurityManager is present -- basically anywhere where code obtained remotely is "hosted" in a container of some kind -- you'll find that the attempt is rejected by the SecurityManager. Under the protection of a SecurityManager the immutability does become absolute.


[Jess in Action][AskingGoodQuestions]
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Take a look at this: http://jqa.tmorris.net/GetQAndA.action?qids=69


Tony Morris
Java Q&A (FAQ, Trivia)
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
This goes to something I tried to gently bait people into discussing before How much do you "enable" a design and how much do you "enforce" it? How much do you bullet-proof your own systems against future maintainers who just don't get the idea and start misusing things?

Maybe I can use "Just Create One" on my team because we all know that creating more instances of some object won't work. Have you ever accidentally created a new servlet instance and tried to make it handle requests? Maybe another team has to do a Singleton to prevent transient developers from shooting their own feet off.

Mr. Gilbert has pointed out threading and synchronizing problems with a class exposing its own monitor. If somebody misuses that monitor it's called "a bug." How much effort do we expend to prevent that or do we just let them suffer the consequences?

Waddya think?
[ October 25, 2005: Message edited by: Stan James ]

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Scott Selikoff
Saloon Keeper

Joined: Oct 23, 2005
Posts: 3704
    
    5

I'm fond of black box model with pure encapsulation such that the user has no freedom at all to maliciously modify the private data. The problem is though, you may limit your code's ability to grow beyond your own work. Still, I think the only exceptions that should ever be visible to the user are ones that the API specifically makes note of.

I can't stand the number of times I've gotten null pointer exceptions 5 levels deep into code that I didn't even have the source for. In practice I've seen little to no real protection for public methods.

In the end, the only way to really prevent misuse is to write thin yet complete java doc APIs.


My Blog: Down Home Country Coding with Scott Selikoff
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
Mr. Gilbert has pointed out threading and synchronizing problems with a class exposing its own monitor. If somebody misuses that monitor it's called "a bug." How much effort do we expend to prevent that or do we just let them suffer the consequences?

Waddya think?


Well, you should know by now that *I*'m very much on the "enabling" side...

Having said that, I feel that that last sentence seems to build on a false dichotomy. I'm all for preventing bugs, and I don't want anyone suffering from anything - I just think there needs to be a balance, and I prefer approaches that don't limit design options. (You can tell that I just finished "Lean Software Development" - I really like the notion of "set based decision making".)

Actually I recently started using explicit monitor objects in my classes - not because I had problems with monitors being misused, but because I can give them more meaningful names that way. And I don't see any negative influences of this approach.

In the Singleton vs. Just Create One case, on the other hand, Singletons cement a design in a way that it's most often simply not worth the price, in my not so humble opinion.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Scott Selikoff:
I'm fond of black box model with pure encapsulation such that the user has no freedom at all to maliciously modify the private data. The problem is though, you may limit your code's ability to grow beyond your own work.


On the other hand, having others depend on implementation details of your classes can significantly hamper the ability of your code to grow at all.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Not so Immutable Strings