You may want to treat all Levels generically (so you'd only need Level to extend JFrame), and keep your individual Level data in a file you load at runtime. This allows you to modify the level without having to recompile your Java program. However, I don't know what data you will need in each Level. If a level will require unique method calls in your code, than clearly yes you will need this structure, I'm just averse to utilizing inheritance for every potential nesting of different objects within one program especially when the change can be represented mostly by differences in internal data rather than usable interface.
Also, I have learned that one of the Ways of Java is to program to Interfaces and abstract classes rather than non-abstract classes:
public abstract class Level extends JFrame
public abstract ActionListener getLevelEventListener();
That way you could make different implementations of the Level class without having to change any of the code that utilizes Level.
public class LevelImpl1 extends Level
// Provide a GUI-based Level implementation
public class LevelImpl2 extends Level
// Provide very different implementation
You may want to just go with an interface and not extend JFrame if code that uses the Level doesn't call JFrame methods. This way the code that uses the Level object is independent of the visual representation of the data within the Level object, making your program more flexible. You could potentially implement River crossing in any other type of window, in fullscreen, or even on the command-line or over the internet. Can't do that by extending JFrame!
EDIT: AH! You just edited it. It's a good idea to have a separate object that represents a piece, but I don't know for sure about the pocket. If you disconnect your Level/Board from the JFrame, you may also want to disconnect Pocket from JButton. It's always a good idea and in good form in Java to capitalize your class names, too.