Rather than go the lower-level (but perhaps more featured) gen-class route, you can get good results using clojure.core/proxy. Proxy lets you define a stub class implementation that can subclass existing classes, call superclass method implementations, override, etc., without having to go the AOT-compiled route the genclass requires. The downside is it's not as fast (e.g. if you're proxying an object with a method invocation that's on a hot path, that's maybe not so good and gen-class or other methods are necessary). In fact, this is pretty common for wrapping swing components (even seesaw does it ).
My recommendation is to try (if interface based) reify | deftype, then proxy, then gen-class, then if it's easier or you're willing, java. Most of my use-cases have been handled through basic clojure interop, without the need for gen-class though.
But in the above case the jframe is already mutable so there's no need for using :state anyway.. Is this thinking correct ?
If you can get a handle on the JFrame, then yes you can mutate it through interop. Since this class inherits from it, then that's plausible. The "state" implementation is sort of a clojure-specific implementation detail for providing an idiomatic way to package your own stuff along with generated classes (rather than, say, a bunch of individual instance vars, you'd typically just pack a map of state - which can include atoms and stuff for mutation if you'd like).
Or is this not possible at all and i should just call a separate function after the object is initialized, something like
You can define your own constructors and map them the the superclass constructor, as shown in this useful guide. I think the "initialize-after" is a fine method and limits the class-specific junk you have to put into gen-class. Since you can still operate on the object via interop...it's a viable and common option.
