Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Not so Immutable Strings

 
Garrett OBrien
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Tony Morris
Ranch Hand
Posts: 1608
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Scott Selikoff
author
Saloon Keeper
Posts: 4014
18
Eclipse IDE Flex Google Web Toolkit
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic