Acoyani Garrido Sandoval

OK, so I have this program, which reads two characters, appends them to a StringBuffer, adds the resulting string to a Vector, and does the same until the end of file is reached.

Now, since I didn't managed to remember or find anything on the documentation about an End Of File flag (I remember you can see if you reached it on C with the feof(An input stream) function), I found that I can use the available() function from the FileInputStream class, which returns how much bytes are between the file pointer and the EOF marker. So, I have a While loop like this:
while (TheFile.available() > 0) { A lot of stuff; More stuff; }

The problem? This code, compiled with JCreator 3.50 LE, worked yesterday in my computer, but it doesn't works anymore! When I run my program, I get the following stack dump (BTW, I think "Controlador no v�lido" translates to "Invalid controller" or something; I've never seen the English version since my computer is in Spanish):
java.io.IOException: Controlador no v�lido at java.io.FileInputStream.available(Native Method) at Rjukan.ArmarLista(Constructor de lista.java:58) at BedoyPuto.main(Prueba de construcci�n de lista.java:18)

Any idea on what could be going on?
[ September 29, 2007: Message edited by: Acoyani Garrido Sandoval ]

As far as I know, the == works with everything but strings. That's why you have the .equals(Some string) method: because this way, you can see if a string is the same as another one.

I don't know if you can use this same method with other data types though. However, I'd rather use the plain ol' ==, because that means "compare", while the .equals() means "go call a function that compares and returns a boolean value", which is of course much, much less efficient.
[ September 09, 2007: Message edited by: Acoyani Garrido Sandoval ]

OK, so one of my teachers from college just made me do a file compressing utility, using the Huffman encoding. I don't have much problem with the code tree, since I've been reading quite a bit about data structures in Java. The problem, however, is with the encoding process itself.

The thing is, that Huffman encoding creates code words of absolutely any length, from 1 bit to whatever the **** you get. But guess what? A computer can only handle full bytes. That's a big problem for me, 'cause I have absolutely no idea on how to handle these "partial bytes", and I don't think padding with zeroes would do, because that would make my program much, much less efficient. I've been looking on the Internets a way to read and handle "partial bytes" with Java, partly because I'm really good at Java, partly because I know absolutely nothing about C++, but so far I've found nothing at all.

Any idea on how can I keep my Huffman encoding efficient?