Should I use Java for a custom Swing component designed for a clojure app?
Asked Answered
A

3

5

I want a simple timeline component (like in video editing software) for a clojure/seesaw app and I am wondering if it is a good approach to implement this directly with clojure and seesaw or if I should write it in java and make my clojure wrapper around it.

Or more generally: is a functional programming language optimal for writing UI widgets? I cannot imagine doing that without a lot of state involved. And wasn't OO invented for UI-development in the first place?

Anjelicaanjou answered 23/3, 2012 at 11:27 Comment(0)
P
4

You could go either way. On Overtone, we've built a number of custom graphical components directly in Clojure with Seesaw. Many times, an atom and (seesaw.core/canvas) is sufficient for this kind of thing.

Depending on how fancy you're going to get, one reason to do it in Clojure is you can extend Seesaw's protocols (selection, binding, etc) to the new widget so it works seamlessly with Seesaw. Another consideration is whether your widget needs to make use of Clojure data from other parts of the app. This will be much cleaner from Clojure than Java.

That said, if you're comfortable in Swing/Java, you can do it there and Seesaw will be perfectly happy to work with a custom widget built in Java. Good luck!

Pushball answered 23/3, 2012 at 14:36 Comment(1)
Using atoms and canvas was my first approach actually but when interaction became more complex I started making a mess. Glad to hear of overtone and that there are actually examples of custom swing components in seesaw.Anjelicaanjou
D
2

FP is good for doing UI programming but for that the underlying UI framework should also be based on FP concepts like FRP etc. In your case the underlying UI framework (Swing) is OO based and hence it would be more easy to implement it in Java but you can still do it in seesaw.

Delectable answered 23/3, 2012 at 11:53 Comment(2)
Thanks. I'll go the java way here. But FRP is an interesting point. Not heard of before. I have to look into that.Anjelicaanjou
Statefulness in itself is no reason not to use Clojure. I find that even for purely interop Clojure code, it is easier to write Java in Clojure than in Java.Abecedary
H
2

All else being equal (i.e. assuming you know both Clojure and Java), I would probably write this as a custom Swing component in Java.

Reasons:

  • Swing is fundamentally a Java-based OOP framework and is a better fit with Java in terms of paradigm
  • Mutable state is easier in Java than in Clojure
  • If you write it in Java, you can use it elsewhere more easily (e.g. as a library from other Java code)
  • It's easy to wrap a Swing component in Clojure after you have created it

Of course, for the application logic itself I would certainly prefer Clojure.

Hoiden answered 23/3, 2012 at 12:2 Comment(3)
Thanks for clarifying. I was tending towards using java for my problem. But maybe more because I am a clojure newbie and feel much more comfortable in java.Anjelicaanjou
This answer is not exactly true. Mutable state for Java objects is just as easy in Clojure as it is in Java.Abecedary
@rplvy - sure you can use (set! (. objectExpr fieldName) expr) but even then that is less convenient than objectExpr.fieldName=expr (especially when you consider lack of static type checking and needing type hints to avoid reflection etc.). Apart from that, you can't use mutable local variables at all which are pretty useful in OOP GUI code. Much as I love Clojure, it's not the most convenient for managing local single-threaded mutable state.Hoiden

© 2022 - 2024 — McMap. All rights reserved.