Java serialization (and, specifically, the Serializable and Exernalizable interfaces) allows you to read/write arbitrarily complicated Java objects, automatically or manually from/to disk or from/to the network. Whereas XML and JSON are textual formats, Java serialization is a binary format. (Serialization is also a general concept of simply reading/writing data, but since the question is about Java, I assume you are referring to the builtin serialization system, i.e. Serializable/Exernalizable)
Advantages of "implements Serializable" over XML/JSON
At first, you get serialization pretty much for free. You don't need to make very many changes to your objects in order to let the serialization mechanism work with it. Another advantage is that, because it is a binary format, it is much more compact than the textual format, and so will probably use less space (which is good for conserving network bandwidth or for conserving storage space on disk).
Disadvantages "implements Serializable" over XML/JSON
The disadvantage to builtin Java serialization is that, if you make changes to your object, making the different serialization formats compatible can really be a major nightmare. Also, whereas you can manually edit XML and JSON, you cannot edit a serialized Java object (without reading it into Java). For the same reasons, it is often easier to debug XML and JSON than binary formats, because XML and JSON are human-readable. Another disadvantage with Java's builtin serialization mechanism is that you cannot (easily) serialize/deserialize the data from another programming language.
Alternative techniques for reading/writing data
There are alternative serialization techniques other than Java's builtin serialization that give you the best of both worlds: compact binary formats, language interoperation, ease of version compatibility, and often debugging tools as well that make it easy to dump the binary data in readable format. For example, Google's opensource protocol buffers and MessagePack are examples of serialization libraries/formats that let you read/write compact binary data and easily maintain version compatibility. The biggest downside of these libraries over builtin Java serialization is that they involve plain-old-data objects for serialization (as opposed to more fully-featured Java objects that also have behavior associated with them); however, this disadvantage is, in fact, an advantage as separating the data model to which/from which the information is stored from the objects that wrap or are derived from them is actually a good programming practice and makes it easier to support multiple formats.
Usage
Since you asked for the need, not merely the definition, there are a number of use cases:
Simply saving your data for use later. For example, let's say you are writing a video game. Your program will not run forever; even if it never crashes (which is hopefully the case), your user will probably exit the program at some point or the operating system may kill the program to save resources (e.g. on Android, background processes that the user is not interacting with are frequently and intentionally killed by the OS to reclaim system resources like RAM). In order to ensure that the user doesn't start from the very beginning and can instead resume from where they were or from the most recent save point, you will want to write the state of the game to persistent storage (i.e. the hard drive, the user's Google Drive account, etc.). In order to do this, you need to translate the data structures in memory that represent the state of the game to raw bytes that you can write to disk (or to whatever system you are saving the data).
Retrieving information from a remote server. Let's continue with the game example... suppose you are creating an online multiplayer game or that you want to make it possible to provide new levels or items in the game without the user updating their app. To do this, you would want the information about the online player or the information about the new levels/items to be communicated from a server computer (which you use as the point of contact for all the copies of the app installed on various devices) to the individual copies of the app. Both the server and app need some sort of in-memory representation of these data structures (e.g. the location of other players, the structure of a new level, the description/image for a new item, etc.), but to transfer the information from the server to the app on the device, the communication system consists of raw bytes, and so it is necessary to have a way to convert the data to raw bytes and from raw bytes back to a meaningful in-memory data structure.
Pretty much any communication between two different processes/apps or between an app and some storage system is a case where some sort of serialization mechanism is required.