Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

finding char in string with specific hex value  RSS feed

 
Jason Abreu
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have written a servlet that reads in a spool file from our AS400 and outputs it, in a browser, using the Adobe Reader plugin.

My input stream has page breaks in it that I need to adhere to, because of page headings in the spool files.

I am currently reading in 1 byte at a time to test for page breaks. I did this for development only so I could make sure the conversion worked.
Now I need to put this in production, so I need to change my red to 10240 bytes at a time.
Is there a fast way to process my byte array up to my page break ("0C" in hex), do my page break, then process the rest of my byte array?

Currently:

[ September 01, 2006: Message edited by: Jason Abreu ]
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16028
87
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is no need at all to convert a byte to a hexadecimal string, and then check if the string matches "0C". Just look at the value of the byte directly.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Look at Scanner in Java 5 and later. It can read up to a delimiter in one chunk. I have to admit I'm only repeating what I read here, have only used Scanner once just to see what it did, and not quite in this context.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The good news is that if you're interested in improving the performance of this code, there's a lot you can do!

Besides what Jesper points out, which is a good one, there's also the issue of catenating Strings together a character at a time, which is horribly inefficient. Instead of building up strPage by adding characters, use a StringBuffer (or StringBuilder in JDK 1.5 or later) and use the "append" method to add the characters, then use toString() to turn the buffer into a String only at the end. The performance improvement due to this alone should be enormous!

Finally, there's the whole "reading one byte at a time" thing, which can be slow if its unbuffered. You may be able to improve performance more by wrapping your PrintObjectTransformedInputStream in a BufferedInputStream, but whether this is true depends on some particulars of your code that I am not privy to.

Now, there is one definite bug here, and one possible issue. The bug is that the "-1" returned at end of file will be processed as valid data before terminating the loop. Instead of a "do...while", this loop should just be a "while" -- the test needs to be at the top, before the processing is done.

The possible issue is that you're assuming that one byte equals one character. I suppose in the specific EBCDIC->ASCII case, this may be a valid assumption, but make sure of that. In the general case, characters can consist of multiple bytes, and so are dealt with using Java's "Reader" and "Writer" classes rather than the "InputStream" and "OutputStream" classes; the latter are ignorant of character encodings.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!