Hello ABCL developers,
has anybody written some macros to make calling Java from ABCL more straightforward? I mean something that, instead of this code from the ABCL documentation:
(defun void-function (param) (let* ((class (jclass "Main")) (intclass (jclass "int")) (method (jmethod class "addTwoNumbers" intclass intclass)) (result (jcall method param 2 4))) (format t "in void-function, result of calling addTwoNumbers(2, 4): ~a~%" result)))
would let you write something like this, for example:
(format t "in void-function, result of calling addTwoNumbers(2, 4): ~a~%" ;; Let's imagine that we have defined a -> macro. (-> |Main.addTwoNumbers| 2 4)
Thank you.
On 2016/3/4 18:54, EGarrulo wrote:
Hello ABCL developers,
has anybody written some macros to make calling Java from ABCL more straightforward? I mean something that, instead of this code from the ABCL documentation:
(defun void-function (param) (let* ((class (jclass "Main")) (intclass (jclass "int")) (method (jmethod class "addTwoNumbers" intclass intclass)) (result (jcall method param 2 4))) (format t "in void-function, result of calling addTwoNumbers(2, 4): ~a~%" result)))
would let you write something like this, for example:
(format t "in void-function, result of calling addTwoNumbers(2, 4): ~a~%" ;; Let's imagine that we have defined a -> macro. (-> |Main.addTwoNumbers| 2 4)
abcl-1.3.3 currently includes code in the ABCL-CONTRIB mechanism for two such additional syntaxes, namely [JFLI-ABCL][1] and [JSS][2].
[1]: http://abcl.org/trac/browser/trunk/abcl/contrib/jfli/README [2]: http://abcl.org/trac/browser/trunk/abcl/contrib/jss/README.markdown
One may load these packages by
```lisp (require :abcl-contrib) (require :jfli) ```
or
```lisp (require :abcl-contrib (require :jss) ```
I don't really know much about JFLI, but use JSS extensively.
The example of ```lisp (-> |Main.addTwoNumbers| 2 4) ```
would become
```lisp (#"addTwoNumbers" 'Main 2 4) ```
in JSS.
Mark Evenson <evenson@...> writes:
(#"addTwoNumbers" 'Main 2 4)
Why do you prefer JSS over JFLI? It seems to me that JFLI would blend better with CL code (except for the unusual choice of not separating sub- words with dashes). But, above all, JFLI generates methods that should be available for code completion, unlike JSS, I think.
On 2016/3/5 21:31, EGarrulo wrote:
Why do you prefer JSS over JFLI? It seems to me that JFLI would blend better with CL code (except for the unusual choice of not separating sub- words with dashes). But, above all, JFLI generates methods that should be available for code completion, unlike JSS, I think.
I used and developed JSS for years before encountering JFLI, so I won't try to claim that my preference originates from anywhere close to a dispassionate position. But if I had to distill a single point of differentiation for my preference, it would be to prefer the dynamic introspection of JSS over the need to explicitly declare Java objects in JFLI. Coming from the static linkage of languages like Java and C, I was initially quite skeptical that the "just name things in Java and let the runtime figure out what you mean" approach of JSS wouldn't encounter catastrophic problems. But over years of developing quite large Common Lisp/Java systems with JSS, I have yet to encounter a single such problem.
I actively encouraged the inclusion JFLI in ABCL-CONTRIB in the desire to encourage and publicize experimentation in different approaches to Java interoperability. In my view, ABCL's strength over say, Clojure, lies in a well defined language core in Common Lisp with built-in extensibility (macros, an easily modifiable reader, etc.) sufficiently powerful to develop various modalities of interoperability with Java. My hunch was that the specifics of interoperability might vary from user to user, and will probably vary over time as well. I am glad that JFLI has more initial appeal to you, as this provides support for this view.
armedbear-devel@common-lisp.net
-
EGarrulo -
Mark Evenson