An interesting read and still worth thinking about, although as some of the comments note, some of the specific behavior the post talks about changed in Java 1.5 (the post is from 2005).
Thanks for noting. Edited the title to make it easier to see (I certainly missed this fact). Howerver, some points it makes are still current, specially about substring chains (which also apply to sub-collections). Most people who use profiles with memory profiling learn these things the hard way...
Seems this at least holds true for Oracle 11g, IBM DB2 10 and Microsoft SQL Server 2008. Of course, this post beeing from 2005 it was none of these versions, but you sort of get the idea :-)
Shouldn't you take into account WHY they have restrictions?
Last time I looked at these kind of restrictions in databases or app servers (some of those have them too), it was clear that some of them were there to protect against the others.
Consider that when company X prohibits this, it immediately gives them an advantage over their competitors, as X can publish benchmarks showing that X is better than the competitors, and the competitors can't run counter benchmarks.
Because of this I've seen where company Y would then add restrictions, but they would not actually prohibit publishing, but rather would require that if company X publishes, the publication must include complete hardware and software configuration information to allow reproduction of the test, and X must grant Y permission to publish benchmark's of X's product on the same terms, regardless of any restriction in X's license.
That is an interesting scenario. Still, it seems like a rather underhanded tactic. Also, I think the OP is talking about a license like the X you mention because I it sounds like he was trying to publish before and after benchmarks, not comparisons with competitors.
Practically every commercial SQL database prohibits publishing profiling data. It's customer hostile and it sucks but there you go. Use a free software licensed SQL database if you want to publish perf numbers.
And that is the main reason why dfsch's substring copies the data (and there is also another operation that explicitly shares the buffer which work only on mutable byte strings).
Sometimes they do matter, but what I gruently had to realize is how few times this is the case (the blog post is a good example - plenty of people here had used Java extensively and never hit these issues).
