Like so many things in GUI application design, which way is best is a matter of tradeoffs that eventually depend on the application itself. There is no right answer that applies across many applications.
Your way will work and can be best in some situations. It does, however, spread the knowledge of the organization of your GUI panels across multiple classes, and that could make maintenance more difficult than it needs to be. If you later want to move some buttons or groups of buttons to another panel for whatever reason, then the access of the data changes, and that means you have to change code in whatever places access the data as well as where the buttons are.
You could, also, design a class that holds just the data for the panel, ensuring that there are NO UI dependencies anywhere in it. Neither Swing nor any other UI package should appear anywhere in the list of imports, and if you wanted to use this class in, say, an SWT or Spring MVC or Windows application, it should be able to work there unchanged. Then provide a reference to a singleton instance of this class to each of your panels, and let them get and set values as they need to. This allows you to change the UI in whatever fashion you like without changing how the data is accessed.
This method supposes that this "data model" for the given frame/dialog is not so complicated that a class to handle it is unduly complex itself. For such a complex frame, you might consider an overall model that was divided into sections, given that different portions of the model only need accessing from certain parts of the UI, and dividing up access among those sections.