Wrapper classes allow primitives to be accessed as objects. For eg, int, char these are primitives and they are not part of the object hierarchy. They are passed by value to methods and cannot be directly passed by reference. Also, there is no way for two methods to refer to the same instance of an int. At times you will need to create an object representation for one of these simple types.
If I understand your question correctly, you are asking what the definition of a wrapper class is?
Essentially, a wrapper class encapsulates (or "wraps") some form of related data. The most general wrapper implements an interface (or sometimes extends a class), and then encapsulates another instance of that class, in order to perhaps moderate or intercept calls to the object.
The best way for me to explain this is to give you a concrete example - this is taken from J2EE Web, but you don't need to know any J2EE to understand it.
In J2EE Web, we have a HttpServletResponse object which (in brief) is used to write data back, via a stream, to the client from the Web server. But sometimes we don't want to write data back directly, sometimes it's appropriate to intercept that data and then decide later whether we want to send it to the client or not. In this case we use a HttpServletResponseWrapper:
Notice that the wrapper is a HttpServletResponse. All our HttpServletResponseWrapper actually does is delegate everything to the enclosed 'wrapped' object - so our wrapper 'looks' just like the enclosed object. Alone this is pretty useless; but if we want to prevent content being written back directly, we can override one or more methods - for example, overriding getWriter() allows us to use an intermediate buffer between the server and client...
We've now got an object which looks almost like the enclosed 'wrapped' instance, but makes a few minor changes and overrides a few methods - but in essence, it shares all the same properties (one might be tempted to say it is almost the same object), and that's what a wrapper is all about - having the same object/properites at heart, but make some exterior modifications.
The primitive wrappers in java.lang are also doing just this, except they enclose/wrap a primitive and not an object. They then go on to add extra useful definitions to methods like toString() and equals(), and add the various xxxValue() methods (I've ignored the static methods, which don't technically form part of a wrapper class); these all add extra detail to the primitives, or modify the way in which the wrapped primitive behaves.
This is the correct way to think about wrappers - this is a well-known design strategy known as the Wrapper or Decorator pattern. Try a search for "Wrapper pattern".
The "Adapter pattern" is similar - in this case, we have a class (ClassA) which provides all the required functionality for some particular purpose, but doesn't implement the correct interface (InterfaceB) to actually be used or passed to any methods as arguments. In this case, all we do is:
instantiating a new wrapper for each instance of ClassA, and passing that wrapper to the methods which take InterfaceB as an argument...
Let me know if that has helped.
Charles Lyons (SCJP 1.4, April 2003; SCJP 5, Dec 2006; SCWCD 1.4b, April 2004)
Author of OCEJWCD Study Companion for Oracle Exam 1Z0-899 (ISBN 0955160340 / AmazonAmazon UK )
Wrapper is a pretty generic term ... for specifics look up Decorator, Adapter and Bridge patterns for a start. Structurally they look a lot alike but the intent and purpose is different in each. If you read up on those and still have questions, scroll on down to the UML, OO etc. forum and ask away.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi