• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Not so Immutable Strings

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
}
}
}
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Take a look at this: http://jqa.tmorris.net/GetQAndA.action?qids=69
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
author
Posts: 4335
39
jQuery Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic