permaculture playing cards*
The moose likes Beginning Java and the fly likes making own InputStreamReader() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "making own InputStreamReader()" Watch "making own InputStreamReader()" New topic
Author

making own InputStreamReader()

benny rusli
Ranch Hand

Joined: Jan 15, 2005
Posts: 72
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.





i want use it later like this :



Any help would be appreciated.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
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:



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 ]

"I'm not back." - Bill Harding, Twister
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
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


Java API Documentation
The Java Tutorial
benny rusli
Ranch Hand

Joined: Jan 15, 2005
Posts: 72
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
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
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
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: making own InputStreamReader()
 
Similar Threads
Reuse of InputStreamReader
Java: Convert a binary file to "text" and back again.
Adding to an Input Stream
read from a file into a string
velmurugan notes (arrays)