Original title: StringBufferInputStream is deprecated, without suitable replacement

java.io.StringBufferInputStream
has been deprecated. However, I cannot find anything
to replace its full functionality.

Specifically, java.util.Properties.load() expects
an InputStream. I want it to read from a String.
StringBufferInputStream was previously the
perfect way to do this. 
Unfortunately, the recommended replacement is
java.io.StringReader, which is subclassed from
Reader, and is NOT usable as an InputStream.

The ideal fix would be to make Reader
implement InputStream.

A lesser fix, would be to document in the
deprecation notes for StringBufferInputStream,
what to do if you really need an InputStream
derived from a String

InputStreamReader seems to go from InputStream to
Reader. Now you need something to go from
Reader to InputStream
(Review ID: 20734)
======================================================================
Posted Date : 2005-07-27 04:36:37.0

There is a suggested fix from   xxxxx@xxxxx   (see Comments).
Posted Date : 2005-11-28 17:59:30.0

A suggested fix from (company - Self , email -   xxxxx@xxxxx  -mlv.fr)
is attached to this report as filename 593432.txt (too large to paste here.)
Posted Date : 2005-11-28 17:59:30.0

======================================================================

A better solution would be to provide a load(Reader)/store(Writer) interface.
Posted Date : 2005-08-23 08:19:59.0

Contribution-Forum:https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?forumID=1463&messageID=10421
Posted Date : 2005-12-06 17:49:07.0

This is my problem EXACTLY.  I have not found a 
suitable replacement.

This particular problem also makes it difficult
to use the java.sql.PreparedStatement.setAsciiStream
method as it requires an InputStream.

ditto.
I cannot find a workaround.
This is particularly irksome, since I was forced
to use the Properties class by the deprecation 
of getenv().  Come on, guys!  If it ain't broke,
don't break it!!

Because there is no properties replacement method
that takes a reader it is very annoying.  Either
consistantly eliminate inputStream and
outputStream EVERYWHERE replacing all methods that
use them with reader and writer equivelents, or 
provide a way to switch BOTH BACK AND FORTH.
-G

I have the same problem...I can't go from Reader
to InputStream...
Does anyone have a workaround?

I have the problem of writing protocol handlers
that need to return an InputStream from getInputStream(),
but since StringBufferInputStream() is deprecated
with a suggestion to use StringReader, can't override
getInputStream to return StringReader.  Please
provide a bridge.

Oh, I'm sorry: it's not a bug (of course), it's a 
'request for enhancement' which is 3 1/2.

I really like the  workaround 
"leave the deprecated class in the code ..." (given in 
4217782). 
The API sais "This class does not properly convert 
characters into bytes.". And I should continue to use it?
What does *that* mean? 
This bug is 3 1/2 years old now. Impressive. 

seems like there are exactly 12 people in the world needing 
this... come on sun, make 12 people less unhappy.

** 13  ** people need a solution!

It's a lot more than 13!

Java Eng:  Come on!  We're comin up on 1.4 - it's time to
take a stand!

With that said, here's a freakishly bad hack just to avoid
the deprecation warning.  It still suffers from the encoding
problem:

ByteArrayInputStream stream = new
ByteArrayInputStream(string.getBytes());
Properties props = new Properties();
props.load(stream);
stream.close();

do something about this. or maybe even give load method in 
Properties to accept Reader.

Who wants a laugh?  You could use only boolean properties, 
and use boolean's getBoolean(String name) which does not 
see if a string is true or false, but instead sees if a 
system property is true or false.  Get Integer does the 
same thing, but with integers.  Hey Sun, how about a 
getString that gets the string value of a system property?

This is an absurd, this bug was introduced in Nov 24, 1997. 
How the hell did sun manage to avoid fixing this. The 
workaround is not good enough.
Please have some shame, and fix this. It's a core functionality 
and its missing since 1997, let me repeat 1997.

I used the StringBufferInputStream with a charset for 
special encoding.
with stringReader there goes no charset and all (500) 
webpages were rendered unreadable.
I changed it back to StringBufferInputStream and it 
worked fine.
i fear the version of the jdk where the class is droped

Does anyone have a work around for converting from Reader to InputStream

OK, now we have Tiger RC and no way of converting a StringReader into an InputStream is in sight. Do we really all have to write our own adapter class ReaderInputStream, that implements InputStream and whose constructor takes an Reader, that it reads from?
- Maybe i have to wait another seven years?

I too am astonished this did not get addressed in Tiger. I don't want a StringBufferInputStream, I just want to be able to use java.util.Properties.load( ) without funky workarounds. The ones I know: 
Workarounds:  
1. convert the String to its byte array, and pass that into a ByteArrayInputStream.
String s = ...;
Properties p = new Properties();
byte[] bArray = s.getBytes();
ByteArrayInputStream bais = new ByteArrayInputStream(bArray);
p.load(bais);

or
  byte[] byteArray = myString.getBytes("ISO-8859-1"); // choose a charset 
  ByteArrayInputStream baos = new ByteArrayInputStream(byteArray); 

2. When converting to a ByteArrayInputStream, this uses the platform's default character           

                encoding. This can potentially lose information. Another option is save to a 

temporary file and read in from file. Be sure to enable delete on exit for the file so it doesn't 

hang around.
3. put info in a permanent file, then read from that file with a FileInputStream. For example:  
import java.io.FileInputStream;
import java.util.Properties;
public class PropertiesTest {
	public static void main(String[] args) throws Exception {
                  // set up new properties object
                  // from file "myProperties.txt"
                  FileInputStream propFile = new FileInputStream(
                                                     "myProperties.txt");
		  // note this initializes the new properties object with the current set		
                  Properties p = new Properties(System.getProperties());
                  p.load(propFile);

                  // set the system properties
                  System.setProperties(p);
                  // display new properties
                  System.getProperties().list(System.out);
	}
          }

try this
new InputStreamReader(new ByteArrayInputStream(Result.getBytes()), 

thnx chengyukpong , this works fine
but are there any possible problems which could arise from using certain encoding/character table ?
this should not happen in my case, however, one never knows :)

in the comment of chengyukpong, you should use Result.getBytes("ISO-8859-1"), because property files are latin-1 encoded.