parse StringBuffer

[Sebastian Green]

Im trying to run through a String Buffer char by char.


while (sb.length() > i) {
System.out.print(sb.charAt(i));
}



It works fine if the sb DO NOT CONTAIN doubble or more new lines (two '\n'). Every char after the '\n's will not be printed out. Dose anyone know why, or dose anyone have a-work-around to parse through the sb and still being able to pick up certain chars?
[ August 20, 2004: Message edited by: Sebastian Green ]

[Sebastian Green]

I edited the, this is my new problem I havent solved.

[Mark Spritzler]

I don't recall any StringBuffer class in J2ME. I think you might have posted this question in the wrong forum.

Mark

[Gregg Bolinger]

Moving to Java In Generail (Intermediate)...

[Adrian Yan]

can you post abit about your code? I wrote a simple test, and it works fine:

public class StringBufferTest{
    public static void main(String args[]) {
        String line = "this is a \n testing line \n cool?";
        int i = 0;
        while (line.length() > i ) {
            System.out.print(line.charAt(i));
            i++;
        }
    }
}

[Sebastian Green]

thx for your time but this belong to J2ME.
http://j2medevices.com/documentation/midp1.0/java/lang/StringBuffer.html


my stringbuffer is a result from a txtfile dosent littary contains '\n' its more like:
This is a
testing line
cool?

But the issue is when there is two breakline like this:

This is a
testing line

cool?

then cool? wont be outprinted...

[JulianInactive KennedyInactive]

Try using java.io.StringReader. It has a readLine() method. If you don't want to output blank lines just check the trimmed line length before you write.

Jules

[Sebastian Green]

Sorry but the MIDP 1.0 dose not have support for java.io.StringReader Thanks anyway...

[Adrian Yan]

I switched the code from String to StringBuffer, and it works fine. Can you print out the line before using charAt command? and see if that works?
From the docs, it looks the java.lang package is a copy of J2SE version, so I don't see any reason why that wouldn't work.

[Sebastian Green]

Thats why I think it is so odd. Perhaps its has something with my geting-inform-from-txt-code
This should work, but it dosent.

private void fetch() {
    HttpConnection httpConnection = null;
    DataInputStream din = null;
  
    try {
      httpConnection = 
        (HttpConnection) Connector.open("http://localhost/txt.txt");
      httpConnection.setRequestProperty(System.getProperty(
        "microedition.platform"), "Profile/MIDP-1.0 Configuration/CLDC-1.0");
      httpConnection.setRequestProperty("Content-Language", "en");
    } catch (Exception e) {
      
    }
  
    StringBuffer sb = new StringBuffer();
    try {
 
      din = httpConnection.openDataInputStream();
      while ((ch = din.read()) != -1) {
        sb.append((char) ch);
      }
    } catch (Exception ex) {
    } finally {
      try {
        din.close();
        httpConnection.close();
      } catch (Exception ex3) {
        
      }
    }
 
    while (sb.length() > i) {
    System.out.print(sb.charAt(i));
    i++
    }   
  }
 

herer is the txt.txt

H
p
d
 
h

The "h" will not be outprinted!

[ edited to break long lines and remove the evil tab characters -ds ]
[ August 22, 2004: Message edited by: Dirk Schreckmann ]

[Adrian Yan]

Just out of curiosity, did you ever try to print the StringBuffer directly without using charAt. System.out.println(sb);? I just want to see if you are actually get the data back into the StringBuffer correctly.

[Sebastian Green]

Yes I have, and gues what, all the data is there. Strange isnt it?

[JulianInactive KennedyInactive]

You could always dig into the source for StringReader and use it as inspiration... USTL, as they used to say.

[Vedhas Pitkar]

Or better still write your own StringBuffer/StringReader. Maybe then you will get a job at Sun & your StringBuffer will be included in Java 6 or Java 1.6 or LION or whatever

[clio katz]

it seems there are really only 2 possibilities:

sb.length() is being mis-reported [confused by dbl-newline], OR

System.out.print() manages to eat the post-dbl-newline chars

you can rule-out #1 by verifying the length is correct before you print:

System.out.println(sb.length());

you can rule-out #2 by printing the ascii code of the char along with or instead of the char - eg:

System.out.print("["+ ((int)sb.charAt(i)) +"-'"+sb.charAt(i)+"']");


can you try this? it's not clear to me whether or not print is being called after the double-newline is encountered...


MISC NOTE: if the file is expected to come from a different OS environment, it may contain different newline char(s) than the client's native OS ... the foreign newline char(s) may be handled differently on the client's out

[Sebastian Green]

This my exact outprint using the Rule 2. Note this is copied frpm EclipseME console, I have the same problem with WTK-console.

[104-'h'][13-'
'][10-'
'][112-'p'][13-'
'][10-'
'][100-'d'][13-'
'][10-'
'][13-'
'][10-'

here is the txt file

 
h
p
d
 
g

dont really know what to get of this. The stranges thing if i use System.out.println then the "g" will be outprinted.

[Adrian Yan]

Can you print out the file and the length to the console?
System.out.println(sb.length());
System.out.println(sb);
I'm really curious about this right now.

[clio katz]

i'm curious too, because based upon your dump, it is actually sb.length() that is "at fault".

i would not be surprised by this, because we can't tell from anything we've seen so far that the charAt(sb.length()+{1...3}) is not being treated by java as '00' (null) ... especially if it's coming from reading a file.

... if you tried to access it [sb.length()+n], you'll undoubtedly get an indexoutofbounds exception

now i'm really curious

it would be instructive to see:

dump of ascii code of each char read by the pgm

final counter from read op (how many times was sb.append() called?)

reported sb.length()

sounds very much like a java bug, but that would depend on the details of this particular scenario ... control chars can be very confounding...

[Layne Lund]

Perhaps the stream's buffer is not flushed before the program ends. Try:

System.out.flush();

at the end of this method.

[yacoob ali]

Hi guys,

Really got interested in the discussion and tried your code but unfortunately it works when i run through intel Idea.
Iam getting different results when i run through idea and through command prompt infact iam using the same class file. Here is the code that i tried

FileInputStream is = new FileInputStream("D:\\test\\test.txt");
StringBuffer sb = new StringBuffer();
while ((ch = is.read()) != -1)
{
sb.append((char) ch);
}
int i = 0;
while (sb.length() > i)
{
System.out.print("["+ ((int)sb.charAt(i)) +"-'"+sb.charAt(i)+"']");
i++ ;
}

The result i got through Idea:
[104-'h'][13-'
'][10-'
'][112-'p'][13-'
'][10-'
'][100-'d'][13-'
'][10-'
'][13-'
'][10-'
'][104-'h']

and through command prompt:
'][10-''][13-'
'][10-''p'][13-'
'][10-''d'][13-'
'][10-'
'][104-'h']

I really don't understand what makes the difference

NOTE:Iam using the same class file

Hope it adds much confusion

regards
Yacoob

[Layne Lund]

ASCII values 10 and 13 are control characters. 10 represents a line feed and 13 a carriage return. (This terminology comes from old manual typewriters, iirc.) I suspect the two environments are simply displaying these characters differently.

p.s. Have you tried adding System.out.flush() after your last while loop?

[Adrian Yan]

Man, this is getting crazy. Layne, i tho System.out flush by default.