This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
As you know, Java™ only supports single inheritance, not multiple inheritance. In the cases you mention, many of the methods are common to buttons and components. Have a look at the documentation for a button and a label; you will find their inheritance hierarchy at the opt of the page. Look where those inheritance trees diverge, and you can work out which methods they have in common and which are disjoint. Choose whichever has the more disjoint methods (I suspect button) and make you class inherit from that. Then, you can say myNewButton instanceof JButton, but you can't get anything sensible from myNewButton instanceof JLabel.
I would reconsider my design if I found myself facing this sort of problem.
I had the same problem, and it didn't take me long to find out that the common superclass of JLabel and JButton is JComponent. Which implies that the setText() method of JLabel and the setText() method of JButton don't have a common ancestor. That's just convergent evolution, if you like.
My solution was the traditional Java solution; if you want two classes to "have the same methods" and to have that mean something, you create an interface with those methods and have each of the two classes implement that interface.
And the other thing that happened, once I decided to use the interface, was that I realized I didn't need to extend JLabel or JButton either. I realized that composition could work for me just as well as inheritance.