making own InputStreamReader()

[benny rusli]

Hello everyone,

i am trying to make my own IO Package, can someone check this and correct it, if it is not good. I do this just for learning. I saw the Api doc, it is written that the only methods that a subclass must implement are read(char[], int, int) and close(). So i implemented it in the code.

package DevelopIO;
import java.io.*;
 
public class MyInputStreamReader extends Reader 
{
    public MyInputStreamReader()
    {
       // super.blabla() what should i put here 
    }

    public int read() throws IOException 
    {
        return super.read();
    }
   
    public int read(char cbuf[], int offset, int length) throws IOException 
    {
return super.read(cbuf, offset, length);
    }
    
    public void close() throws IOException 
    {
super.close();
    }
}

i want use it later like this :

BufferedInputStream bsr = new BufferedInputStream(System.in);
MyInputStreamReader isr = new MyInputStreamReader(bsr);
BufferedReader br = new BufferedReader(isr);        
String value = br.readLine();

Any help would be appreciated.

[Jim Yingst]

It's hard to tell what the purpose of this excercise is - you want to duplicate the InputStreamReader functionality? Do you know anything about character encoding? I suspect this is not really a very good project - it's a bit complex, and the amount of effort that will go into figuring it out may be somewhat pointless considering that InputStreamReader already does what you need, doesn't it? Perhaps you could just look at the source code for InputStreamReader instead? However, if you're doing this just for the learning benefit, it may still be worthwhile.

Right now, your code doesn't compile. The error messages you get will point you to the problem. When you override abstract methods, you cannot access the super.method() versions of those methods. Because they're abstract. Your job here is to provide an implementation of read(char[], int, int) and close() - you can't do that by referring back to an abstract method. There's nothing there. You could get this to compile at least by putting in dummy implementations that do nothing:

    public int read(char cbuf[], int offset, int length) throws IOException
    {
        return 0;
    }
 
    public void close() throws IOException
    {
        
    }

But what will you put here later? Well, that's the whole point of this project, right? Figuring that out...

As far as your constructor, I don't think there's any point to having a no-argument constructor anyway, is there? You want to be able to instantiate the class with "new MyInputStreamReader(bsr)", you'll need a constructor that takes an InputStream argument.

I hope that helps...
[ January 21, 2006: Message edited by: Jim Yingst ]

[Layne Lund]

You haven't really implemented anything here. First of all the posted code will not even compile since Reader.close() and Reader.read(char[] cbuf, int off, int len) are both abstract so you cannot call them with the super keyword. This is typically the first test to see if your code is "good". Also for now, you probably shouldn't bother implementing the read() method that doesn't take any parameters. The default implementation in Reader.read() probably calls the read(char[], int, int) method that you DO need to implement.

So to actually implement an InputStreamReader, you need to use an InputStream somewhere, right? You might take a look at the java.util.InputStreamReader from the Java API for suggestions for how this might work (at least at the interface level). For example, the constructor should probably take the InputStream as a parameter to the constructor. You will need to figure out how to read the bytes from the InputStream and convert them into characters. This will probably involve some kind of character encoding. You should decide whether or not you plan on supporting multiple encoding schemes.

As you develop this, it will be difficult for us to tell if your code is good just by looking at it. I suggest that you learn how to use "test driven development" so you can assure yourself that it is correct. You might be interested in using JUnit to help write test cases for your class. Google for more information on both "test driven development" and JUnit.

Good luck and keep coding!

Layne

[benny rusli]

Hello people,

thanks for responding my question. You are both right in this case, the project is too difficult and complex for me, its not easy as i thought. How about to make a File Tree like JFileChooser ? I want to make my own File Tree with the package javax.swing.JTree, I want to make the File Tree in GUI extending JFrame. The left side is the File Tree and the right side is JTextArea, so that i can drag and drop the file, that i want to zip, to the right side like Explorer Browser from Windows. The zip and jar program can be made from java.util.jar and java.util.zip, i have finished making it for compress and uncompress both file or directory. What do you think about this project, it is easy to implement ?
The other starting point is : making a Frame by extending JFrame and put JPanel on Swing Container and then use GridBagLayout to arrange or put the Component JTree on the left side and the Component JTextArea on the right side.

By the way, whether junit a program to test java algorithm or what ? it that same like this "Parasoft Jtest�" from http://www.parasoft.com/jsp/home.jsp but this commercial. Is that meaningful to test every java algorithm that we make ? i meant, when should we test the java code that we make, is that depending on how many rows that have been created or what ?

Any comments would be appreciated.

[Layne Lund]

I'm not familiar with Parasoft's JTest, but from the brief glance I gave the link you posted, it looks like part of JTest does similar things as JUnit does. I am willing to bet it has many more features to do other things.

As for testing, you should ALWAYS test EVERY line of code that you write. Otherwise, how do you know your program works correctly? Of course, in large systems this is often difficult to do, but it is a decent goal to have. If you have done any development, you have probably done more testing than you know. Just running a program is a basic test that shows that it actually starts. Frameworks like JUnit just help automate testing so that you can run your tests again and again without taking as much time as it does to run them manually.

Layne

[Paul Clapham]

If you are going to use drag-and-drop with a JTree as your target, don't use the drag-and-drop features built into Swing components. If you do that then you can't have the drop behave differently based on what tree node you're dropping on. (At least if you can, it certainly wasn't obvious to me how to do that.) You'll have to write your own drag-and-drop from scratch using mouse listeners and so on. It took me quite a while to get that 90% right, which is where I am at so far. (Still haven't got around to convincing it that dragging the scroll bar doesn't constitute dragging something in the panel, and if my drop action pops up a dialog box the panel still thinks its being dragged over when I move the mouse to click a button in the dialog.)

Maybe that helps you to decide if it's too difficult? It's hard to tell what your level of ability is.