extend String (somehow!)

[Ike]

I have to read from a Socket, every second, and if a value returned from the
socket changes, I need to do something. The data in the input stream
terminates with a (char)0x0d (ASCII 13).

Thus, I am each second, filling a char array until the terminating character
is reached, then, converting the char array to String, as follows below:

char c4[] = new char[1024];
is = new BufferedReader(new InputStreamReader(sock.getInputStream()));
while((c3=(char)is.read())!=(char)0x0d){
i++;
c4=c3;
}
String returnedString =new String(c4); //its a shame I cannot extend String
somehow to be ascii 13 terminated!

I think there are some much more efficient ways to do what I am trying to do
here (for one, I am recreating a new String each second!). In addition, I am
wondering if I am slowing things down by using a BufferedReader as opposed
to a straight InputStreamReader.

Can anyone point out ways I can make this more efficient? Thanks, Ike

 

[Stefan Schulz]

char c4[] = new char[1024];
is = new BufferedReader(new InputStreamReader(sock.getInputStream()));
while((c3=(char)is.read())!=(char)0x0d){
i++;
c4=c3;
}
String returnedString =new String(c4); //its a shame I cannot extend String
somehow to be ascii 13 terminated!

I think there are some much more efficient ways to do what I am trying to do
here (for one, I am recreating a new String each second!). In addition, I am
wondering if I am slowing things down by using a BufferedReader as opposed
to a straight InputStreamReader.

Can anyone point out ways I can make this more efficient? Thanks, Ike

Are you sure the overhead is as substantial as you believe? Constructing
and discarding a String _once a second_ is not that much of a waste. You
are using Java, after all... and let's just say, if that truely is a
significant impact on your application's performance, you might want to
look into C or Assembly.

You are definitly slowing things down by using a BufferedReader... if
you can implement buffering in a better way then it does. However,
consider the price/payoff. The price for a BufferedReader (and a new
String) is miniscule. The price in writing the new code, and debugging
it if it does not run right away can be steep.

 

[Paul Lutus]

Ike wrote:

/ ...

its a shame I cannot extend
String somehow to be ascii 13 terminated!

There are reasons you should not do this, but you certainly can if you want.
Just extend String and create a new "toString()" method that does what you
want.

I think there are some much more efficient ways to do what I am trying to
do here (for one, I am recreating a new String each second!).

So why not look at other people's code that does this, amnd compare it to
your own?

In addition,
I am wondering if I am slowing things down by using a BufferedReader as
opposed to a straight InputStreamReader.

Can anyone point out ways I can make this more efficient?

A lot of reading and study will help. If you want a short, complete answer,
post a short, complete program.

 

[Thomas Schodt]

I think there are some much more efficient ways to do what I am trying to do
here (for one, I am recreating a new String each second!). In addition, I am
wondering if I am slowing things down by using a BufferedReader as opposed
to a straight InputStreamReader.

Can anyone point out ways I can make this more efficient? Thanks, Ike

read() raw bytes instead.

create your own
String readLine()
method that reads bytes, and convert to String and return
only once you hit a 0x0d byte.


BufferedReader just means it reads as much as it can
and then hands it off to you in chunks (whatever you ask for),
so you are likely to slow things down by not using buffering,
but use BufferedInputStream to get bytes instead.

 

[Pete Glasscock]

There are reasons you should not do this, but you certainly can if you want.
Just extend String and create a new "toString()" method that does what you
want.

final

 

[Joona I Palaste]

There are reasons you should not do this, but you certainly can if you want.
Just extend String and create a new "toString()" method that does what you
want.

And how exactly do you suppose he can "just extend String"?

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge

 

[Paul Lutus]

And how exactly do you suppose he can "just extend String"?

My mistake -- String is final, yes? Okay, then, a class that exploits a
String rather then extends the String class. Same basic point.

 

[Steve Horsley]

I have to read from a Socket, every second, and if a value returned from the
socket changes, I need to do something. The data in the input stream
terminates with a (char)0x0d (ASCII 13).

Thus, I am each second, filling a char array until the terminating character
is reached, then, converting the char array to String, as follows below:

char c4[] = new char[1024];
is = new BufferedReader(new InputStreamReader(sock.getInputStream()));
while((c3=(char)is.read())!=(char)0x0d){
i++;
c4=c3;
}
String returnedString =new String(c4); //its a shame I cannot extend String
somehow to be ascii 13 terminated!

I think there are some much more efficient ways to do what I am trying to do
here (for one, I am recreating a new String each second!). In addition, I am
wondering if I am slowing things down by using a BufferedReader as opposed
to a straight InputStreamReader.

Can anyone point out ways I can make this more efficient? Thanks, Ike

I would be inclined to take the lazy way and use BufferedReader's readLine()
method. This identifies the line endings for you, and returns the String:

while((String inString = is.readLine()) != null) {
System.out.println("I just got " + inString);
}

The returned String has the \r character stripped, but that shouldn't matter
to you. I really don't think efficiency is something you should be worrying
about here. Not at one string/second. At a thousand strings a second, I might
be tempted to do it all in byte[] instead.

Beware that your InputStreamReader constructor should really be specifying
the characterset that the network connection uses, probably "ASCII" or
"ISO8859-1". Otherwise it will use the platform default, whatever that may be.

Steve

 

[ak]

My mistake -- String is final, yes? Okay, then, a class that exploits a
String rather then extends the String class. Same basic point.

wow! Paul admitted that he made mistake!

 

[Paul Lutus]

wow! Paul admitted that he made mistake!

Are you serious? I admit mistakes all the time. The only requirement is that
it be a mistake. Use Google to disabuse yourself of your present
misconception.

 

[ak]

My mistake -- String is final, yes? Okay, then, a class that exploits a

Are you serious?

I am ironical

I admit mistakes all the time. The only requirement is that
it be a mistake.

However THIS mistake (java basics) says very much...

Use Google to disabuse yourself of your present
misconception.

I saw shortly very long thread, where you was unable to do it.

 

[Paul Lutus]

I am ironical

However THIS mistake (java basics) says very much...

It says what it says. No more, no less.

I saw shortly very long thread, where you was unable to do it.

I was right, moron. Now stop simultaneously trolling and stalking -- do one
or the other.

 

[ak]

My mistake -- String is final, yes? Okay, then, a class that
exploits

It says what it says. No more, no less.

It says that you are relative new to java.
But instead of reading some java stuff you trying to teach others... Bad
idea.

I was right, moron. Now stop simultaneously trolling and stalking -- do one
or the other.

Don't speak to yourself.