I think the difficulty arises because you have view (Swing) objects storing application state. In a desktop application I know the controller and view sometimes are merged partially or entirely, but the model should still be separate.
When developing such applications, I like to use the following approach:
- Some code (could be main, an event listener, whatever) triggers a new view into existence.
- A factory of some sort constructs the MVC elements:
- View: prefer to use standard Swing classes and assemble them together.
- Model: create an object to handle one of two types of data. One, persistent state which was likely passed on from the enclosing controller. Two, state which is used by this new view (temporary objects that may be shared).
- Controller: construct more listeners and attach them to the view objects. They will also typically have references to the model objects so they can act on them.
- Next, wire everything up. Add listeners to the view. Use common objects between them when appropriate so they can see the same data and all update the view as necessary.
I believe you are asking the wrong question: using the above approach may be able to solve your dilemma (I cannot say for sure, I do not see your code).
I also highly recommend avoiding global variables, static state, etc. I like to create
Context objects which contain state applicable to the entire application or portion thereof which would normally be a "global variable" to a less experienced developer. This context contains only those variables which are truly needed to be shared across objects, such as the current file (or file abstraction), logged in user, or other state that can legitimately affect all objects in an application or module.
Reducing coupling like that makes individual elements more reusable. While the code may be more verbose and (at first) difficult to follow, it really does streamline it and make it easier in the end. Remember your SOLID principles.