Do you get any errors during compilation? Have you tried using the java.io package for what you need?

Since Java 1.3 (I'm actually not sure of the exact version, but somewhere down the line), the Java standard requires that all your source files be in a package. You can still put your code in the Default Package but if you try to access it from a different package you won't be able to. Packages are simply folders (Oracle says they are "code groupings") where you put your code to have it organized and prevent things like naming conflicts etc. NetBeans creates a package named after the project by default and you should put your code there for now. If you want to use code from a different package, you can simply import it by using the import keyword. If anything, you could read through http://download.oracle.com/javase/tutorial/java/package/packages.html (Package tutorial from Oracle), but the wording might be a little bit tough.


If you could, try recompiling the TextIO and paste any error you get here.

As far as java.io goes, basically the Java language gives you a standard library with classes of various functionality organized into packages. java.io is a input/output package and contains classes that let you perform input and output operations. There are other useful packages like java.awt, java.swing, or java.util. The Java API documentation (so all the packages Java provides for you) are described here. At the top left you have all the packages, below that you have all the classes contained in that package, and in the center you have a fairly detailed description of the class selected and all of it's functions and members. When you get more into programming, you'll find yourself swimming in it, but for now you should just bookmark it and continue on with any learning material you have if any .

First off, sorry for my delayed reply, but I was busy with a side project of my own and I got a little over occupied, forgetting anything outside of it.

To get to the point, NetBeans is definitely a good environment to go with. I use it all the time and so far it hasn't disappointed me. Java is also a good language to start with and has good general purpose use. The differences between java.io and TextIO is that TextIO is a wrapper and java.io is native to the language. Basically speaking, java.io is part of the actual language and TextIO is built on top of of it all. As an analogy, imagine a bicycle and a motorcycle. On a bike, you have to pedal manually to get the bike moving, which is equivalent to using the java.io package: you have to do more labor to achieve what you want. The TextIO package is equivalent to the engine on the motorcycle: with a twist of the handle (and messing with the gears, yadda yadda) you get the engine to act on the wheel automatically without bothering you too much.

Anyhow, the compiler says that the line in question will never be reached. I take it that this:



private static void fillBuffer() { // Wait for user to type a line and press return,
// and put the typed line into the buffer.
StringBuffer b = new StringBuffer();
out.flush();
try {
int ch = in.read();
if (ch == '\n' && possibleLinefeedPending)
ch = in.read();
possibleLinefeedPending = false;
while (ch != -1 && ch != '\n' && ch != '\r') {
b.append((char)ch);
ch = in.read();
}
possibleLinefeedPending = (ch == '\r');
if (ch == -1) {
System.out.println("\n*** Found an end-of-file while trying to read from standard input!");
System.out.println("*** Maybe your Java system doesn't implement standard input?");
System.out.println("*** Program will be terminated.\n");
throw new RuntimeException("End-of-file on standard input."); // line 536
}
}
catch (IOException e) {
System.out.println("Unexpected system error on input.");
System.out.println("Terminating program.");
System.exit(1);
}
buffer = b.toString();
pos = 0;
}


is the code in question. Hmm, I can't tell why the compiler seems to be complaining about it. Perhaps your code is different than the above?

EDIT: This class, while it does import java.io, doesn't really have much to do with file IO. It turns out that it deals with console IO. I didn't notice that because of an exceptional package: the java.lang package. It is included everywhere by default, so everything inside of that java.lang package can be used without importing it.

Indeed, one of the uses of a wrapper is to make something complicated simple (or automated if you will). It's like putting buttons on an electronic device so that it's user can operate it without concerning him or herself with the underlying circuitry. The buttons still use the circuitry to perform their functions, but the user doesn't have to worry about it. There are other uses, but this one is relevant to the code at hand.

Hah, that function is exactly the same as the one I found The Java API states that StringBuffer and StringBuilder are actually the same classes, but StringBuffer is designed for programs that make use of threading. Threading is, simply put, multi-tasking, and is a fairly complicated and messy process: hard to implement even for the most seasonal programmers it seems (I haven't had the need for it yet). Technically, both StringBuffer and StringBuilder are legal, but StringBuilder is faster because it doesn't have to synchronize with other tasks.

Some wrappers can be shared and some can be indeed comparable to OEM parts. Wrappers have a whole array of useful functionality, they can also serve as a means to get "cross-platform" functionality (the write once, run everywhere type).

As for threading, I'm not sure exactly why or how it came to be, but my guess is that it came before multi-core processors. Whereas true multi-tasking programs can only be achieved on a multi-core processor, threading is actually implemented by the operating system and can be pulled off on a single core system. The latest OS that I'm sure could run more than one process was Windows 95 and that system I'm pretty sure came before dual core CPUs were invented. Don't worry about asking questions: it's a forum for beginners anyhow.