L'expédition d'une application de bureau Clojure est-elle réaliste?

J'expédie actuellement une application Java de bureau. Il s'agit d'une ancienne et simple application Java 5 Java / Swing et jusqu'à présent, tout fonctionnait bien. Java 5 a été ciblé parce que certains utilisateurs étaient sur une version OS X / des ordinateurs qui n'auront jamais Java 6 (nous pouvons lever cette limitation bientôt et passer à un Java plus récent et abandonner simplement mes utilisateurs coincés avec Java 5).

Je me familiarise rapidement avec Clojure, mais je n'ai pas encore fait beaucoup de Clojure-à-Java et Java-à-Clojure et je me demandais s'il était réaliste de livrer une application de bureau Clojure au lieu d'une application Java ?

L'application que j'expédie est actuellement d'environ 12 Mo avec tous les .jar, donc l'ajout de Clojure ne semble pas trop poser problème.

Mon plan serait d'avoir des API Java appelées par Clojure: mon application est déjà divisée en plusieurs pots indépendants.

Si je comprends bien, appeler Clojure à partir de Java est plus difficile que d'appeler du code Java à partir de Clojure, c'est pourquoi je réécrirais essentiellement toute l'interface utilisateur (une partie de l'interface utilisateur, mélanger les composants Swing et les images tamponnées auto-créées doit être réécrite de toute façon en raison de l'augmentation) d'affichage de la rétine), et faire tout le «câblage» de Clojure.

C'est donc le problème auquel je suis confronté: est-il réaliste de livrer une application de bureau Clojure? (Cela ne semble certainement pas être très répandu, mais l'envoi d'applications de bureau Java simples n'est pas non plus courant et je le fais quand même)

Techniquement, que faudrait-il faire? (par rapport à l'envoi d'une application Java)

Oui, c'est tout à fait réaliste - peu de gens semblent le faire encore mais je pense que ce n'est qu'une question de temps (Clojure est assez nouveau après tout!)

J'ai personnellement écrit un jeu open-source dans Clojure qui fonctionne comme une application Swing (https://github.com/mikera/ironclad) alors j'ai quelques expériences à partager qui peuvent être utiles.

• En moyenne, vous souhaitez probablement avoir un appel Clojure dans les API Java. C'est surtout du bon sens - Java a toutes les grandes bibliothèques, Clojure est le langage le plus productif pour coller des choses ensemble.
• Vous voudrez peut-être écrire un "chargeur" ​​basé sur Java avec une main(...)méthode qui lance la partie Clojure du code. Entre autres choses, cela signifie que vous n'aurez pas à AOT compiler votre code Clojure. Exemple de code ici: https://github.com/mikera/ironclad/blob/master/src/main/java/ic/IronClad.java
• Vous voudrez probablement faire des choses comme lancer un écran de démarrage pendant que votre application s'initialise pour permettre le temps de démarrage supplémentaire de chargement / compilation du code Clojure. Cela ajoute probablement 1 à 2 secondes à un temps de démarrage d'application typique, ce qui suffit pour que votre utilisateur apprécie probablement certains commentaires. Si vous êtes intelligent, vous pouvez réellement lancer toute l'interface utilisateur pendant que d'autres choses se chargent en arrière-plan, mais cela nécessite un peu de soin et pourrait tester votre kung-fu concurrent :-)
• Vous pouvez mélanger Java et Clojure relativement librement car ils peuvent appeler en arrière et en avant de manière assez transparente. La seule complication si vous voulez que Java appelle Clojure est que Java aime connaître la classe / interface qu'il appelle au moment de la compilation. Une bonne option est d'avoir le code Clojure implémenter dynamiquement une interface Java déjà compilée via reify .
• J'ai trouvé assez facile de développer et de conditionner une application dans un seul pot contenant à la fois du code Clojure et Java à l'aide d'Eclipse / Maven. Le code Clojure peut simplement être inséré src/main/resourceset est chargé / compilé au moment de l'exécution.
• Vous pouvez utiliser des wrappers GUI Clojure comme la balançoire si vous le souhaitez. Cela semble assez bon. J'ai décidé de ne pas l'utiliser, principalement parce que je voulais faire des choses délicates avec Swing directement et je ne pensais pas que j'avais besoin d'une couche supplémentaire d'abstraction.