'out' is an object of OutputStream class .Then why we use it with system class as we write System.out.print();
Aaah. Yes, this is interesting. System.out.print (and println) are static methods. That means you can use them without creating objects first. Java is an OOP environment, so this is a short-cut for using methods without all the code needed to first initialize the objects they belong to. Think of System.out.print as being "tied" to the output stream of the console. You can redirect System.out to a file, a printer or any other device that can handle a stream. By default though, it is tied to the console. You are in fact sending data to a output stream using System.out. Hope this helps.
But why we need to call using System class. Why we not use it using OutputSteam class whose instance is it
The System class is a class you use to make life easier. Instead of you having to create a link to the standard output, you simply use this utility method in the System class. The "out" builds on PrintStream, which builds on FilterOutputStream which builds on OutputStream. So you save yourself a lot of work going this route. The "out" method is in the System class, so you call it by calling System.out, with the "." meaning the "out" of the "System" object. Are you learning Java? If so, how well do you understand OOP? It makes a lot more sense if you understand OOP. It's a bit of a foreign concept in the beginning and can be very overwhelming. Remember, each object needs to be created before you can use it, but the "out" in System is a STATIC method, so you don't need to create it everytime you want to output something to the console. Does this help a bit more?
In essence, what OOP tries to do for you is save time by having different objects interact with each other without necessarily understanding each others specific functions. Read this article on OOP which will help you a lot, not only in Java but in OOP in general: http://walk2rem.blogspot.com/2005/10/what-is-oop-in-layman-terms_27.html Hope that helps.
Here's more information on it: Object oriented programming is like volleyball. First, someone out there defines a class called volleyball, with rules, actions, methods, etc., enabling anyone to play a game or "instantiate" (a term specifically created for OOP, meaning "to begin an instance"). As many volleyball games can go on at one time as needed, as space provides, around the world. The game itself is the object "volleyball," created from a specific class called "volleyball" (same name as the object [actually, the object will take the same name as the class]). And, as the rules of the class volleyball change, so too do the games [objects] as they are played [created]. Now, I take my little analogy pretty far in my own head, describing the players as the variables, the serve as a "constructor" (a specific method that creates an object), etc. The one thing, though, that I think is important to realize is that most objects will be slightly different, based on user input, time of day, whatever (because you wouldn't use OOP for anything static); so, objects are defined individually by three things: a state, an identity and behaviors. These might be, for example, the score (technically, the state is defined by the value of an object's fields or variables), the teams playing each other [identity], and the specific actions or behaviors that have occurred during play (sets, spikes, etc.). Oh, and the last important thing: when the game is over, it no longer exists. So too, the object disappears from the world when the user is done. [This is where I have found all other metaphors I've seen to fall short.] Sort of... (someone pointed out to me that you might specifically want to write your program to a database for easy access to "Volleyball's Most Shocking Moments" or something.) http://evolt.org/node/542
And even more info and another analogy: A good introductory way to explain object-oriented programming is by using the cat analogy. Your cat Stinky is an object and an instance of the class 'cat,' which is in turn derived from the class 'reptile.' Your cat has members and methods. Some members (e.g. legs, hind legs) and methods (e.g. "Feed," "Pat," "Kick") are public, while others (e.g. stomach, pancreas, "Digest food") are private. However, you are never supposed to access public member objects as part of an interface, as this could cause the cat to be dismembered. An interface is something that a cat has in common with any other thing. Like any other pet (turtle, rock, canary), it can be starve() it or kick() it. Like any other furred thing (tiger, buffalo), you can skin() it. If you trade pelts, then it doesn't matter that your pet is a cat, only that it has fur of some sort. Using this analogy, one can explain the various criticisms levelled against OOP. For example, it would obviously be easier, as in conventional programming, to have all members conveniently accessible, so when you want the cat to say, digest food, you don't have to crack its body open to get at the stomach. Another attack is to say that data could get all balled up in the object; you would have to make the cat cough the furball (data) up in order to gain the sweets of profit off it. http://uncyclopedia.wikia.com/wiki/Object_Oriented_Programming
In System.out.println, System is a class in java.lang package and all class created by you will import from system class. Out is a field in the system class.It's also object of the outputstream class. And println is a method for printing defined in the outputstream class.
[FONT=Arial, Helvetica]When the proponents of growth, market deregulation, and free trade tout their benefits, it is well to bear in mind what some of the most outspoken of these proponents really have in mind. Take this account from a recent issue of Forbes magazine. [/FONT]