| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| When Java switched it's reliance from I''''''nputStream and O''''''utputStream to Reader and Writer, Sun didn't provide any way to create an I''''''nputStream from a Reader. This is especially noticed as the S''''''tringBufferInputStream was deprecated and Properties is dependendent on I''''''nputStream, not Reader. |
=== Of Streams, Readers and Writers === When Java switched it's reliance from I''''''nputStream and O''''''utputStream to Reader and Writer (at least, for text streams), Sun didn't provide any way to create an I''''''nputStream from a Reader. This is especially noticed as the S''''''tringBufferInputStream was deprecated and Properties is dependendent on I''''''nputStream, not Reader. |
| Line 4: | Line 6: |
|
=== What is my appserver doing with all of the CPU time? === I ran into an issue with a servlet application (running under W''''''ebLogic Server), was consuming an inordinate amount of CPU time. Profiling the application did not turn up any indication of why, presumably because the CPU was being used by a thread other than the one being profiled. Consulting with Bea led me to capturing information pinpointing which thread was consuming the time. See JavaTidbits/ThreadDump for the details. |
Of Streams, Readers and Writers
When Java switched it's reliance from InputStream and OutputStream to Reader and Writer (at least, for text streams), Sun didn't provide any way to create an InputStream from a Reader. This is especially noticed as the StringBufferInputStream was deprecated and Properties is dependendent on InputStream, not Reader.
Here's [http://nitric.com/jnp/source/jnp-src/ReaderInputStream.java ReaderInputStream.java] to the rescue.
What is my appserver doing with all of the CPU time?
I ran into an issue with a servlet application (running under WebLogic Server), was consuming an inordinate amount of CPU time. Profiling the application did not turn up any indication of why, presumably because the CPU was being used by a thread other than the one being profiled. Consulting with Bea led me to capturing information pinpointing which thread was consuming the time.
See JavaTidbits/ThreadDump for the details.