«

Roedy Green wrote:
> Hmm. The String class code has changed. The new code avoids pinning
> large blocks of RAM, but it does more System.arrayCopys.

Nope, not the case, unless you're thinking of something different from
me. The issue here has always been that String.substring resulted in
saving the entire character data from the original String, and that
still happens. The code you quoted:

> public String substring(int beginIndex, int endIndex) {
> [argument checking]
> return ((beginIndex == 0) && (endIndex == count)) ? this :
> new String(offset + beginIndex, endIndex - beginIndex,
> value);
> }

Note that, assuming this isn't the trivial case of a no-op substring,
the functionality comes down to the constructor String(int,int,char[]).
Perhaps you're confusing that with String(char[],int,int) -- but they
are really quite different. The former constructor, which is used here,
does not perform a single copy of the data at all, but merely reuses the
same array, but creates a new value with different offsets and lengths
so as to preserve the character array.

So the same problem still exists.

The constructor that you quote, on the other hand, does make a copy if
the underlying data is larger than what is desired. That's a special
feature of that constructor, not something that's inherent to all
constructors.

> The question now is, when did it change?
>

And the answer, I think, is that it never did.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

On Tue, 22 Jun 2004 00:53:00 -0400, Sudsy <>
wrote or quoted :

>
>Roedy: I hate to mention this, but you're one of those people.
>You recently ranted against XML. We can now justify using a text-
>based interchange format precisely because the costs of memory
>and bandwidth have dropped.

Bandwidth is may be cheap but it is nowhere near fast enough for
psychological comfort. We need to stop washing our feet in bandwidth
and treat it like a precious resource, the way we used to treat RAM,
for a least another 5 years.

Even if you feel comfy with a T1 most of your customers are getting by
with much less.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

On Tue, 22 Jun 2004 00:53:00 -0400, Sudsy <>
wrote or quoted :

>I hate to mention this, but you're one of those people.
>You recently ranted against XML.

XML is flagrant conspicuous waste. See Veblen's Theory of the Leisure
Class.
http://www.amazon.com/exec/obidos/AS...nadianmindprod

XML is waste for the sake of waste.

I find it morally repugnant.


--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

On Tue, 22 Jun 2004 00:53:00 -0400, Sudsy <>
wrote or quoted :

>XML combined with base64 encoding also accomodates encryption,
>enveloped, enveloping, whatever.

Now there's another assinine idea -- ASCII armouring on 8-bit
transparent channels.

Arrgh. I have invented Base64u which at least avoids the waste of
cascading encoding base64 and url-encoding.

see http://mindprod.com/jgloss/armouring.html


--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Roedy Green wrote:
> On Tue, 22 Jun 2004 00:53:00 -0400, Sudsy <>
> wrote or quoted :
>
>
>>XML combined with base64 encoding also accomodates encryption,
>>enveloped, enveloping, whatever.
>
>
> Now there's another assinine idea -- ASCII armouring on 8-bit
> transparent channels.

Why? It avoids many of the pitfalls associated with vendor-specific
protocol implementations. Does a file termination flag consist of
^Z, a NULL, a null byte, or none of the above?
Would you prefer a mix of text and binary? Even MIME uses encoding
rules. Do you wish to revert to the days when you couldn't attach
data in any format but text?
PKC using asymmetric keys makes perfect sense to me.
I guess I just don't understand your dismissal of XML. While you
rail against it, you unintentionally provide justification for its
popularity.
Quite obviously YMV.

On Tue, 22 Jun 2004 05:38:57 GMT, Roedy Green
<look-> wrote or quoted :

>
>XML is flagrant conspicuous waste. See Veblen's Theory of the Leisure
>Class.
>http://www.amazon.com/exec/obidos/AS...nadianmindprod
>
>XML is waste for the sake of waste.
>
>I find it morally repugnant.

I have got to put together a proper XML logo. It will be one of those
grossly obese Hawaiian women who were kept in huts and fed huge
amounts of poi to make them fat as possible. They were so fat they
could not move and had to be hauled about on slings. Remember Alii Nui
Queen Malama in Hawaii?

I tease the XML creators with a purported photo of the inventors on my
website at http://mindprod.com/jgloss/xml.html


--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

> Note that new String does not necessarily make a copy, though it does
> create a new String object.

Of course it does.
String is immutable (JLS 3.10.5) (almost:
http://www.xdweb.net/~dibblego/java/...nswers.html#q1)
hence the ability to immediately deduce that the original statement was very
blatantly incorrect.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

On Tue, 22 Jun 2004 05:08:07 GMT, Roedy Green
<look-> wrote or quoted :

> return ((beginIndex == 0) && (endIndex == count)) ? this :
> new String(offset + beginIndex, endIndex - beginIndex,

This means a technique of coding I often use that used to be very
efficient is now very costly.

I would process a giant string in chunks and keep carving off a tiny
chunk off the head, like this looping


rest = rest.substring( smalloffset );


Now instead will have to keep track of where I am in the giant string
instead and do all offset relative to the very start.

I was wondering why it was doing GC so frequently.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

On Tue, 22 Jun 2004 02:14:50 -0400, Sudsy <>
wrote or quoted :

>Why? It avoids many of the pitfalls associated with vendor-specific
>protocol implementations.

The current scheme is a protocol everyone has to use, and it is
inefficient in terms of bandwidth, and is clumsy to process. You
could simply send the data down the wire in binary without farting
around with layers of wrapping. If you have an error-correcting
protocol it is not as if you need to scan for start of record.

We are using protocols that are solving problems that don't exist
anymore, e.g. 7 bit channels, and lost data characters.

You could treat sockets almost as casually as files.


--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

On Tue, 22 Jun 2004 16:41:21 +1000, "Tony Morris"
<> wrote or quoted :

>Of course it does.
>String is immutable (JLS 3.10.5) (almost:
>http://www.xdweb.net/~dibblego/java/...nswers.html#q1)
>hence the ability to immediately deduce that the original statement was very
>blatantly incorrect.

Not so. Substring USED to simply record an offset into the base
immutable char array. It did not need to make a copy. This is part of
the beauty of Java. Sun was able to change the way this worked without
me noticing.

This all worked because Strings are immutable.

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.