1 | \input texinfo |
---|
2 | @setfilename abcl.info |
---|
3 | @settitle Armed Bear Common Lisp User Manual |
---|
4 | @afourpaper |
---|
5 | @set EDITION 1.1.0 |
---|
6 | |
---|
7 | |
---|
8 | @c Editing Hints |
---|
9 | @c |
---|
10 | @c Use emacs. Use M-x texinfo-all-menus-update to update menus. |
---|
11 | |
---|
12 | |
---|
13 | @c Some index prettification helper macros, for tricking the texindex |
---|
14 | @c collation "engine" (from sbcl's manual) |
---|
15 | @macro earmuffs{name} |
---|
16 | *\name\* |
---|
17 | @end macro |
---|
18 | @macro setf{name} |
---|
19 | (setf \name\) |
---|
20 | @end macro |
---|
21 | |
---|
22 | |
---|
23 | |
---|
24 | @c for install-info |
---|
25 | @dircategory Software development |
---|
26 | @direntry |
---|
27 | * abcl: (abcl). Armed Bear Common Lisp |
---|
28 | @end direntry |
---|
29 | |
---|
30 | @copying |
---|
31 | @quotation |
---|
32 | This manual is part of ABCL. ABCL is licensed under the terms of the |
---|
33 | GPL v2 of June 1991 with the ``classpath-exception'' (see the file |
---|
34 | @file{COPYING} in the source distribution for the license, term 13 in |
---|
35 | the same file for the classpath exception). This license broadly means |
---|
36 | that you must distribute the sources to ABCL, including any changes you |
---|
37 | make, together with a program that includes ABCL, but that you are not |
---|
38 | required to distribute the sources of the whole program. Submitting |
---|
39 | your changes upstream to the ABCL development team is actively |
---|
40 | encouraged and very much appreciated, of course. |
---|
41 | @end quotation |
---|
42 | @end copying |
---|
43 | |
---|
44 | |
---|
45 | @titlepage |
---|
46 | @title Armed Bear Common Lisp User Manual |
---|
47 | @subtitle Version 1.1.0 |
---|
48 | @subtitle December 5, 2012 |
---|
49 | @author Mark Evenson |
---|
50 | @author Erik H@"ulsmann |
---|
51 | @author Rudolf Schlatte |
---|
52 | @author Alessio Stalla |
---|
53 | @author Ville Voutilainen |
---|
54 | |
---|
55 | @page |
---|
56 | @vskip 0pt plus 1filll |
---|
57 | @insertcopying |
---|
58 | @end titlepage |
---|
59 | |
---|
60 | @ifnottex |
---|
61 | |
---|
62 | @node Top |
---|
63 | @top abcl |
---|
64 | |
---|
65 | @menu |
---|
66 | * Introduction:: |
---|
67 | * Running ABCL:: |
---|
68 | * Interaction with Java:: |
---|
69 | * Implementation Dependent Extensions:: |
---|
70 | * Beyond ANSI:: |
---|
71 | * Contrib:: |
---|
72 | * History:: |
---|
73 | * Concept Index:: |
---|
74 | * Function Index:: |
---|
75 | * Variable Index:: |
---|
76 | * Type Index:: |
---|
77 | * Colophon:: |
---|
78 | @end menu |
---|
79 | |
---|
80 | @end ifnottex |
---|
81 | |
---|
82 | @contents |
---|
83 | |
---|
84 | |
---|
85 | |
---|
86 | |
---|
87 | @node Introduction |
---|
88 | @chapter Introduction |
---|
89 | |
---|
90 | Armed Bear Common Lisp (ABCL) is an implementation of Common Lisp that |
---|
91 | runs on the Java Virtual Machine. It compiles Common Lisp to Java 5 |
---|
92 | bytecode, providing the following integration methods for interfacing |
---|
93 | with Java code and libraries: |
---|
94 | |
---|
95 | @itemize |
---|
96 | @item |
---|
97 | Lisp code can create Java objects and call their methods. @xref{Calling |
---|
98 | from Lisp to Java}. |
---|
99 | @item |
---|
100 | Java code can call Lisp functions and generic functions, either directly |
---|
101 | (@pxref{Calling from Java to Lisp}) or via @t{JSR-223} (@pxref{Java |
---|
102 | Scripting API (JSR-223)}). |
---|
103 | @item |
---|
104 | @code{jinterface-implementation} creates Lisp-side implementations of |
---|
105 | Java interfaces that can be used as listeners for Swing classes and |
---|
106 | similar. |
---|
107 | @end itemize |
---|
108 | |
---|
109 | ABCL is supported by the Lisp library manager QuickLisp |
---|
110 | (@url{http://quicklisp.org/}) and can run many of the programs and |
---|
111 | libraries provided therein out-of-the-box. |
---|
112 | |
---|
113 | |
---|
114 | @menu |
---|
115 | * Conformance:: |
---|
116 | * Contributors:: |
---|
117 | @end menu |
---|
118 | |
---|
119 | @node Conformance |
---|
120 | @section Conformance |
---|
121 | |
---|
122 | ABCL aims to be be a fully conforming ANSI Common Lisp implementation. |
---|
123 | Any other behavior should be reported as a bug. ABCL is currently a |
---|
124 | (non)-conforming ANSI Common Lisp implementation due to the following |
---|
125 | known issues: |
---|
126 | |
---|
127 | @itemize |
---|
128 | @item |
---|
129 | The generic function signatures of the @code{DOCUMENTATION} symbol do |
---|
130 | not match the specification. |
---|
131 | |
---|
132 | @item |
---|
133 | The @code{TIME} form does not return a proper @code{VALUES} environment |
---|
134 | to its caller. |
---|
135 | |
---|
136 | @item |
---|
137 | When merging pathnames and the defaults point to a @code{JAR-PATHNAME}, |
---|
138 | we set the @code{DEVICE} of the result to @code{:UNSPECIFIC} if the |
---|
139 | pathname to be be merged does not contain a specified @code{DEVICE}, |
---|
140 | does not contain a specified @code{HOST}, does contain a relative |
---|
141 | @code{DIRECTORY}, and we are not running on a MSFT Windows |
---|
142 | platform.@footnote{The intent of this rather arcane sounding deviation |
---|
143 | from conformance is so that the result of a merge won't fill in a |
---|
144 | @code{DEVICE} with the wrong "default device for the host" in the sense |
---|
145 | of the fourth paragraph in the CLHS description of |
---|
146 | @code{MERGE-PATHNAMES} (see the paragraph beginning "If the |
---|
147 | @code{PATHNAME} explicitly specifies a host and not a device@dots{}"). |
---|
148 | A future version of the implementation may return to conformance by |
---|
149 | using the @code{HOST} value to reflect the type explicitly.} |
---|
150 | |
---|
151 | @end itemize |
---|
152 | |
---|
153 | Somewhat confusingly, this statement of non-conformance in the |
---|
154 | accompanying user documentation fulfills the requirements that ABCL is a |
---|
155 | conforming ANSI Common Lisp implementation according to the Common Lisp |
---|
156 | HyperSpec. Clarifications to this point are solicited. |
---|
157 | |
---|
158 | |
---|
159 | @menu |
---|
160 | * Contemporary Common Lisp:: |
---|
161 | @end menu |
---|
162 | |
---|
163 | @node Contemporary Common Lisp |
---|
164 | @subsection Contemporary Common Lisp |
---|
165 | |
---|
166 | In addition to ANSI conformance, ABCL strives to implement features |
---|
167 | expected of a contemporary Common Lisp, i.e. a Lisp of the post-2005 |
---|
168 | Renaissance. |
---|
169 | |
---|
170 | The following known problems detract from ABCL being a proper |
---|
171 | contemporary Common Lisp. |
---|
172 | |
---|
173 | @itemize |
---|
174 | |
---|
175 | @item |
---|
176 | An incomplete implementation of interactive debugging mechanisms, namely |
---|
177 | a no-op version of @code{STEP}, no support for inspecting local |
---|
178 | variables in a given call frame, and no support for resuming a halted |
---|
179 | computation at an arbitrarily selected call frame. |
---|
180 | |
---|
181 | @item |
---|
182 | Incomplete streams abstraction, in that ABCL needs suitable abstraction |
---|
183 | between ANSI and Gray streams. The streams could be optimized to the |
---|
184 | JVM NIO abstractions at great profit for binary byte-level |
---|
185 | manipulations. |
---|
186 | |
---|
187 | @item |
---|
188 | Incomplete documentation (missing docstrings from exported symbols |
---|
189 | and the draft status of this user manual). |
---|
190 | |
---|
191 | @end itemize |
---|
192 | |
---|
193 | |
---|
194 | @node Contributors |
---|
195 | @section Contributors |
---|
196 | |
---|
197 | @itemize |
---|
198 | @item |
---|
199 | Philipp Marek (Thanks for the markup) |
---|
200 | |
---|
201 | @item |
---|
202 | Douglas Miles (Thanks for the whacky IKVM stuff and for keeping the |
---|
203 | flame alive in the dark years) |
---|
204 | |
---|
205 | @item |
---|
206 | Alan Ruttenberg (Thanks for JSS) |
---|
207 | |
---|
208 | @item |
---|
209 | and of course |
---|
210 | @emph{Peter Graves} |
---|
211 | @end itemize |
---|
212 | |
---|
213 | |
---|
214 | |
---|
215 | |
---|
216 | @node Running ABCL |
---|
217 | @chapter Running ABCL |
---|
218 | |
---|
219 | ABCL is packaged as a single jar file usually named either |
---|
220 | @file{abcl.jar} or possibly something like @file{abcl-1.1.0.jar} if |
---|
221 | using a versioned package on the local filesystem from your system |
---|
222 | vendor. This jar file can be executed from the command line to obtain a |
---|
223 | REPL@footnote{Read-Eval Print Loop, a Lisp command-line}, viz: |
---|
224 | |
---|
225 | @example |
---|
226 | cmd$ java -jar abcl.jar |
---|
227 | @end example |
---|
228 | |
---|
229 | @emph{N.b.} for the proceeding command to work, the @code{java} |
---|
230 | executable needs to be in your path. |
---|
231 | |
---|
232 | To facilitate the use of ABCL in tool chains such as SLIME, the Superior |
---|
233 | Lisp Interaction Mode for Emacs, we provide both a Bourne shell script |
---|
234 | and a @code{DOS} batch file. If you or your administrator adjusted the |
---|
235 | path properly, ABCL may be executed simply as: |
---|
236 | |
---|
237 | @example |
---|
238 | cmd$ abcl |
---|
239 | @end example |
---|
240 | |
---|
241 | Probably the easiest way of setting up an editing environment using the |
---|
242 | Emacs editor is to use QuickLisp and follow the instructions at |
---|
243 | @url{http://www.quicklisp.org/beta/#slime}. |
---|
244 | |
---|
245 | |
---|
246 | @menu |
---|
247 | * Options:: |
---|
248 | * Initialization:: |
---|
249 | @end menu |
---|
250 | |
---|
251 | @node Options |
---|
252 | @section Options |
---|
253 | |
---|
254 | ABCL supports the following command line options: |
---|
255 | |
---|
256 | @table @option |
---|
257 | @item --help |
---|
258 | displays a help message. |
---|
259 | |
---|
260 | @item --noinform |
---|
261 | Suppresses the printing of startup information and banner. |
---|
262 | |
---|
263 | @item --noinit |
---|
264 | suppresses the loading of the @file{~/.abclrc} startup file. |
---|
265 | |
---|
266 | @item --nosystem |
---|
267 | suppresses loading the @file{system.lisp} customization file. |
---|
268 | |
---|
269 | @item --eval FORM |
---|
270 | evaluates @var{FORM} before initializing the REPL. |
---|
271 | |
---|
272 | @item --load FILE |
---|
273 | loads the file @var{FILE} before initializing the REPL. |
---|
274 | |
---|
275 | @item --load-system-file FILE |
---|
276 | loads the system file @var{FILE} before initializing the REPL. |
---|
277 | |
---|
278 | @item --batch |
---|
279 | evaluates forms specified by arguments and in the initialization file |
---|
280 | @file{~/.abclrc}, and then exits without starting a REPL. |
---|
281 | @end table |
---|
282 | |
---|
283 | All other command line arguments, as well as all arguments following the |
---|
284 | occurrence of a double hyphen (@option{--}) are passed unprocessed into a |
---|
285 | list of strings accessible via the variable |
---|
286 | @var{ext:*command-line-argument-list*} from within ABCL. |
---|
287 | |
---|
288 | @defvar @earmuffs{command-line-argument-list} |
---|
289 | This variable contains a (possibly empty) list of command-line |
---|
290 | arguments. Any arguments that were processed already (e.g., |
---|
291 | @option{--load FILE}) are removed from this list. |
---|
292 | @end defvar |
---|
293 | |
---|
294 | |
---|
295 | @node Initialization |
---|
296 | @section Initialization |
---|
297 | |
---|
298 | If the ABCL process is started without the @samp{--noinit} flag, it |
---|
299 | attempts to load a file named @file{.abclrc} in the user's home |
---|
300 | directory and then interpret its contents. |
---|
301 | |
---|
302 | The user's home directory is determined by the value of the JVM system |
---|
303 | property @code{user.home}. This value may or may not correspond |
---|
304 | to the value of the @env{HOME} system environment variable, at the |
---|
305 | discretion of the JVM implementation that ABCL finds itself |
---|
306 | hosted upon. |
---|
307 | |
---|
308 | |
---|
309 | |
---|
310 | @node Interaction with Java |
---|
311 | @chapter Interaction with Java |
---|
312 | |
---|
313 | ABCL is a Common Lisp implementation hosted on a Java Virtual Machine. |
---|
314 | This chapter describes the mechanisms by which the implementation |
---|
315 | interacts with that hosting mechanism. This interactions can go in two |
---|
316 | directions: Lisp-to-Java and Java-to-Lisp. |
---|
317 | |
---|
318 | |
---|
319 | @menu |
---|
320 | * Calling from Lisp to Java:: |
---|
321 | * Calling from Java to Lisp:: |
---|
322 | * Java Scripting API (JSR-223):: |
---|
323 | @end menu |
---|
324 | |
---|
325 | @node Calling from Lisp to Java |
---|
326 | @section Calling from Lisp to Java |
---|
327 | |
---|
328 | ABCL offers a number of mechanisms to interact with Java from its |
---|
329 | Lisp environment. It allows calling both instance and static methods |
---|
330 | of Java objects, manipulation of instance and static fields on Java |
---|
331 | objects, and construction of new Java objects. |
---|
332 | |
---|
333 | When calling Java routines, some values are automatically converted from |
---|
334 | Lisp values to Java values. These conversions apply to strings, |
---|
335 | integers and floats. Other values need to be converted to their Java |
---|
336 | equivalents by the programmer before calling the Java object method. |
---|
337 | Java values returned to Lisp are also converted back to their Lisp |
---|
338 | counterparts. If this conversion is not desired, certain Lisp-to-Java |
---|
339 | functions have ``raw'' counterparts which do not perform any conversion. |
---|
340 | These are recognizable by their name ending with @code{-RAW}. |
---|
341 | |
---|
342 | This section covers the low-level Lisp-to-Java API of ABCL. |
---|
343 | Functions in this section are available after evaluating @code{(require |
---|
344 | 'JAVA)}. A higher level Java API, developed by Alan Ruttenberg, is |
---|
345 | available in the @file{contrib/} directory and described later in this |
---|
346 | document, @pxref{JSS}. |
---|
347 | |
---|
348 | |
---|
349 | @menu |
---|
350 | * Creating Java objects:: |
---|
351 | * Accessing Java object and class fields:: |
---|
352 | * Calling Java Methods:: |
---|
353 | * Calling Java Static Methods:: |
---|
354 | * Parameter matching for FFI dynamic dispatch:: |
---|
355 | * Implementating Java interfaces in Lisp:: |
---|
356 | * Implementation of Java classes in Lisp:: |
---|
357 | @end menu |
---|
358 | |
---|
359 | @node Creating Java objects |
---|
360 | @subsection Creating Java objects |
---|
361 | |
---|
362 | Java objects can be created from Lisp by calling a constructor from the |
---|
363 | class of the object to be created. The @code{JAVA:JCONSTRUCTOR} |
---|
364 | primitive is used to acquire a constructor reference. |
---|
365 | |
---|
366 | @defun jconstructor (class-ref &rest parameter-class-refs) |
---|
367 | Returns a reference to the Java constructor of @var{CLASS-REF} |
---|
368 | accepting the given @var{PARAMETER-CLASS-REFS}. If |
---|
369 | @var{PARAMETER-CLASS-REFS} is a single integer, the first method with |
---|
370 | the given number of parameters is returned instead. |
---|
371 | @end defun |
---|
372 | |
---|
373 | The obtained constructor can be passed as an argument to |
---|
374 | @code{JAVA:JNEW}, together with any arguments. @code{JAVA:JNEW} can |
---|
375 | also be invoked with a string naming the class as its first argument. |
---|
376 | |
---|
377 | @defun jnew (constructor &rest args) |
---|
378 | Creates a new Java object by invoking @var{CONSTRUCTOR} with arguments |
---|
379 | @var{ARGS}. @var{CONSTRUCTOR} can be a constructor reference or a |
---|
380 | string naming a class. |
---|
381 | @end defun |
---|
382 | |
---|
383 | |
---|
384 | @node Accessing Java object and class fields |
---|
385 | @subsection Accessing Java object and class fields |
---|
386 | |
---|
387 | Fields in Java objects can be accessed using the getter and setter |
---|
388 | functions @code{JAVA:JFIELD} and @code{(SETF JAVA:JFIELD)}. Static |
---|
389 | (class) fields are accessed the same way, but with a class object or |
---|
390 | string naming a class as first argument. |
---|
391 | |
---|
392 | Like @code{JAVA:JCALL} and friends, values returned from these accessors |
---|
393 | carry an intended class around, and values which can be converted to |
---|
394 | Lisp values will be converted. |
---|
395 | |
---|
396 | @defun jfield (class-ref-or-field field-or-instance @ |
---|
397 | &optional instance value) |
---|
398 | |
---|
399 | Retrieves or modifies a field in a Java class or instance. |
---|
400 | |
---|
401 | Supported argument patterns: |
---|
402 | |
---|
403 | @table @code |
---|
404 | |
---|
405 | @item class-ref field-name |
---|
406 | Retrieve the value of static field @var{field-name} of class |
---|
407 | @var{class-ref}. |
---|
408 | |
---|
409 | @item class-ref field-name instance-ref |
---|
410 | Retrieves the value of a class field of the instance. |
---|
411 | |
---|
412 | @item class-ref field-name primitive-value: |
---|
413 | Stores @var{primitive-value} in static field @var{field-name}. |
---|
414 | |
---|
415 | @item class-ref field-name instance-ref value |
---|
416 | Stores @var{value} in a class field of the instance. |
---|
417 | |
---|
418 | @item class-ref field-name nil value |
---|
419 | Stores value in a static field (when value may be confused with an |
---|
420 | instance-ref). |
---|
421 | |
---|
422 | @item field-name instance |
---|
423 | Retrieves the value of a field of the instance. The class is derived |
---|
424 | from the instance. |
---|
425 | |
---|
426 | @item field-name instance value |
---|
427 | Stores value in a field of the instance. The class is derived from the |
---|
428 | instance. |
---|
429 | @end table |
---|
430 | @end defun |
---|
431 | |
---|
432 | |
---|
433 | @node Calling Java Methods |
---|
434 | @subsection Calling Java Methods |
---|
435 | |
---|
436 | Methods on a java object method in the low-level (basic) API can be |
---|
437 | called in two ways: |
---|
438 | |
---|
439 | @itemize |
---|
440 | @item |
---|
441 | Calling a specific method reference (which was previously acquired) |
---|
442 | |
---|
443 | @item |
---|
444 | Dynamic dispatch using the method name and the call-specific arguments |
---|
445 | provided by finding the best match (@pxref{Parameter matching for FFI dynamic dispatch}). |
---|
446 | @end itemize |
---|
447 | |
---|
448 | @defun jmethod (class-ref method-name &rest parameter-class-refs) |
---|
449 | Returns a reference to the Java method @var{method-name} of |
---|
450 | @var{class-ref} accepting the given @var{parameter-class-refs}. If |
---|
451 | @var{parameter-class-refs} is a single integer, the first method with |
---|
452 | the given number of parameters is returned instead. |
---|
453 | |
---|
454 | The function @code{java:jmethod} is used to acquire a specific method |
---|
455 | reference. Its first argument is a Java class designator (a |
---|
456 | @code{java:java-class} object returned by @code{java:jclass} or a |
---|
457 | string naming a Java class). The second argument is a string naming |
---|
458 | the method. |
---|
459 | |
---|
460 | Any arguments beyond the first two should be strings naming Java |
---|
461 | classes, with one exception as listed in the next paragraph. These |
---|
462 | classes specify the types of the arguments for the method. |
---|
463 | |
---|
464 | When @code{java:jmethod} is called with three parameters and the last |
---|
465 | parameter is an integer, the first method by that name and matching |
---|
466 | number of parameters is returned. |
---|
467 | @end defun |
---|
468 | |
---|
469 | Once a method reference has been acquired, it can be invoked using |
---|
470 | @code{java:jcall}, which takes the method as the first argument. The |
---|
471 | second argument is the object instance to call the method on, or |
---|
472 | @code{NIL} in case of a static method. Any remaining parameters are |
---|
473 | used as the remaining arguments for the call. |
---|
474 | |
---|
475 | @defun jcall (method instance &rest args) |
---|
476 | @defunx jcall-raw (method instance &rest args) |
---|
477 | Invokes the Java method @var{method} on @var{instance} with arguments |
---|
478 | @var{args}. @var{Method} can be a method reference acquired via |
---|
479 | @code{jmethod} or a string naming a method. The @code{-raw} version |
---|
480 | does not attempt to coerce the arguments or result into a Lisp object. |
---|
481 | @end defun |
---|
482 | |
---|
483 | |
---|
484 | @node Calling Java Static Methods |
---|
485 | @subsection Calling Java Static Methods |
---|
486 | |
---|
487 | Like non-static methods, references to static (class) methods can be |
---|
488 | acquired by using the @code{java:jmethod} primitive. Static methods are |
---|
489 | called with @code{java:jstatic} instead of @code{java:jcall}. |
---|
490 | |
---|
491 | @defun jstatic (method class &rest args) |
---|
492 | @defunx jstatic-raw (method class &rest args) |
---|
493 | Invoke the static method @var{method} on class @var{class} with |
---|
494 | @var{args}. The @code{-raw} version does not attempt to coerce the |
---|
495 | arguments or result into a Lisp object. |
---|
496 | @end defun |
---|
497 | |
---|
498 | Like @code{java:jcall}, @code{java:jstatic} supports dynamic dispatch by |
---|
499 | passing the name of the method as a string instead of passing a method |
---|
500 | reference. The parameter values should be values to pass in the |
---|
501 | function call instead of a specification of classes for each parameter. |
---|
502 | |
---|
503 | |
---|
504 | @node Parameter matching for FFI dynamic dispatch |
---|
505 | @subsection Parameter matching for FFI dynamic dispatch |
---|
506 | |
---|
507 | The algorithm used to resolve the best matching method given the name |
---|
508 | and the arguments' types is the same as described in the Java Language |
---|
509 | Specification. Any deviation should be reported as a bug. |
---|
510 | |
---|
511 | @c % ###TODO reference to correct JLS section |
---|
512 | |
---|
513 | |
---|
514 | @menu |
---|
515 | * Dynamic dispatch Caveats:: |
---|
516 | @end menu |
---|
517 | |
---|
518 | @node Dynamic dispatch Caveats |
---|
519 | @subsubsection Dynamic dispatch: Caveats |
---|
520 | |
---|
521 | Dynamic dispatch, i.e., invoking a Java method via method name instead |
---|
522 | of method reference, is performed by using the Java reflection API. |
---|
523 | Generally the dispatch works fine, but there are corner cases where the |
---|
524 | API does not correctly reflect all the details involved in calling a |
---|
525 | Java method. An example is the following Java code: |
---|
526 | |
---|
527 | @example |
---|
528 | ZipFile jar = new ZipFile("/path/to/some.jar"); |
---|
529 | Object els = jar.entries(); |
---|
530 | Method method = els.getClass().getMethod("hasMoreElements"); |
---|
531 | method.invoke(els); |
---|
532 | @end example |
---|
533 | |
---|
534 | Even though the method @code{hasMoreElements()} is public in |
---|
535 | @code{Enumeration}, the above code fails with |
---|
536 | |
---|
537 | @example |
---|
538 | java.lang.IllegalAccessException: Class ... can |
---|
539 | not access a member of class java.util.zip.ZipFile\$2 with modifiers |
---|
540 | "public" |
---|
541 | at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65) |
---|
542 | at java.lang.reflect.Method.invoke(Method.java:583) |
---|
543 | at ... |
---|
544 | @end example |
---|
545 | |
---|
546 | This is because the method has been overridden by a non-public class and |
---|
547 | the reflection API, unlike @code{javac}, is not able to handle such a case. |
---|
548 | |
---|
549 | While code like that is uncommon in Java, it is typical of ABCL's FFI |
---|
550 | calls. The code above corresponds to the following Lisp code: |
---|
551 | |
---|
552 | @lisp |
---|
553 | (let* ((jar (jnew "java.util.zip.ZipFile" "/path/to/some.jar")) |
---|
554 | (els (jcall "entries" jar))) |
---|
555 | (jcall "hasMoreElements" els)) |
---|
556 | @end lisp |
---|
557 | |
---|
558 | @noindent |
---|
559 | except that the dynamic dispatch part is not shown. |
---|
560 | |
---|
561 | To avoid such pitfalls, all Java objects in ABCL carry an extra field |
---|
562 | representing the ``intended class'' of the object. That class is used |
---|
563 | first by @code{JAVA:JCALL} and similar to resolve methods; the actual |
---|
564 | class of the object is only tried if the method is not found in the |
---|
565 | intended class. Of course, the intended class is always a super-class of |
---|
566 | the actual class -- in the worst case, they coincide. The intended class |
---|
567 | is deduced by the return type of the method that originally returned the |
---|
568 | Java object; in the case above, the intended class of @code{ELS} is |
---|
569 | @code{java.util.Enumeration} because that is the return type of the |
---|
570 | @code{entries} method. |
---|
571 | |
---|
572 | While this strategy is generally effective, there are cases where the |
---|
573 | intended class becomes too broad to be useful. The typical example |
---|
574 | is the extraction of an element from a collection, since methods in |
---|
575 | the collection API erase all types to @code{Object}. The user can |
---|
576 | always force a more specific intended class by using the @code{JAVA:JCOERCE} |
---|
577 | operator. |
---|
578 | |
---|
579 | @c % \begin{itemize} |
---|
580 | @c % \item Java values are accessible as objects of type JAVA:JAVA-OBJECT. |
---|
581 | @c % \item The Java FFI presents a Lisp package (JAVA) with many useful |
---|
582 | @c % symbols for manipulating the artifacts of expectation on the JVM, |
---|
583 | @c % including creation of new objects \ref{JAVA:JNEW}, \ref{JAVA:JMETHOD}), the |
---|
584 | @c % introspection of values \ref{JAVA:JFIELD}, the execution of methods |
---|
585 | @c % (\ref{JAVA:JCALL}, \ref{JAVA:JCALL-RAW}, \ref{JAVA:JSTATIC}) |
---|
586 | @c % \item The JSS package (\ref{JSS}) in contrib introduces a convenient macro |
---|
587 | @c % syntax \ref{JSS:SHARPSIGN_DOUBLEQUOTE_MACRO} for accessing Java |
---|
588 | @c % methods, and additional convenience functions. |
---|
589 | @c % \item Java classes and libraries may be dynamically added to the |
---|
590 | @c % classpath at runtime (JAVA:ADD-TO-CLASSPATH). |
---|
591 | @c % \end{itemize} |
---|
592 | |
---|
593 | |
---|
594 | @node Implementating Java interfaces in Lisp |
---|
595 | @subsection Implementating Java interfaces in Lisp |
---|
596 | |
---|
597 | ABCL can use the Java reflection-based proxy feature to implement Java |
---|
598 | interfaces in Lisp. It has several built-in ways to implement an |
---|
599 | interface, and supports definition of new ones. The |
---|
600 | @code{JAVA:JMAKE-PROXY} generic function is used to make such |
---|
601 | proxies. |
---|
602 | |
---|
603 | @deffn {Generic Function} jmake-proxy interface implementation @ |
---|
604 | &optional lisp-this |
---|
605 | |
---|
606 | Returns a proxy Java object implementing the provided interface(s) |
---|
607 | using methods implemented in Lisp - typically closures, but |
---|
608 | implementations are free to provide other mechanisms. |
---|
609 | |
---|
610 | @code{interface} is a Java interface metaobject (e.g. obtained by |
---|
611 | invoking @code{jclass}), or a string naming a Java interface. |
---|
612 | @code{implementation} is the object used to implement the interface -- |
---|
613 | several built-in methods of jmake-proxy exist for various types of |
---|
614 | implementations. @code{lisp-this} is an object passed as first |
---|
615 | argument to the functions implementing the Lisp ``methods'' of the |
---|
616 | interface, and defaults to @code{NIL}. |
---|
617 | |
---|
618 | The @var{implementation} argument can be of type: |
---|
619 | |
---|
620 | @table @code |
---|
621 | @item function |
---|
622 | The given function will be called with two or more arguments (method |
---|
623 | name, @var{lisp-this}, method arguments if applicable) upon any method |
---|
624 | invocation on the proxy object. Useful for interfaces with a single |
---|
625 | method, or to implement custom interface-implementation strategies. |
---|
626 | |
---|
627 | @item hash-table |
---|
628 | |
---|
629 | The Java interface method names are used as keys in the given hash |
---|
630 | table to obtain the functions implementing them. Functions will be |
---|
631 | called with one or more arguments (@var{lisp-this}, method arguments |
---|
632 | if applicable). |
---|
633 | |
---|
634 | @item package |
---|
635 | The Java interface method names are mapped to symbols in |
---|
636 | @code{package}. A method called @code{javaMethodName} is mapped to a |
---|
637 | Lisp symbol @code{JAVA-METHOD-NAME}. An error is signaled if no such |
---|
638 | symbol exists in the package, or if the symbol exists but does not |
---|
639 | name a function. Functions will be called with one or more arguments |
---|
640 | (@var{lisp-this}, method arguments if applicable). |
---|
641 | |
---|
642 | @end table |
---|
643 | @end deffn |
---|
644 | |
---|
645 | The returned proxy is an instance of the interface, with methods |
---|
646 | implemented with Lisp functions, and can be passed to Java methods |
---|
647 | expecting an instance of the given interface. |
---|
648 | |
---|
649 | |
---|
650 | @node Implementation of Java classes in Lisp |
---|
651 | @subsection Implementation of Java classes in Lisp |
---|
652 | |
---|
653 | @defun jnew-runtime-class (class-name &rest args @ |
---|
654 | &key (superclass @code{java.lang.Object}) interfaces @ |
---|
655 | constructors methods fields (access-flags @code{'(public)}) @ |
---|
656 | annotations) |
---|
657 | |
---|
658 | Creates and loads a Java class with methods calling Lisp closures as |
---|
659 | given in @var{methods}. @var{class-name} and @var{super-name} are |
---|
660 | strings, @var{interfaces} is a list of strings, @var{constructors}, |
---|
661 | @var{methods} and @var{fields} are lists of constructor, method and |
---|
662 | field definitions, respectively. |
---|
663 | |
---|
664 | Constructor definitions - currently NOT supported - are lists of the |
---|
665 | form @code{(argument-types function &optional |
---|
666 | super-invocation-arguments)} where @var{argument-types} is a list of |
---|
667 | strings and @var{function} is a lisp function of @code{(1+ (length |
---|
668 | argument-types))} arguments; the instance (@code{this}) is passed in |
---|
669 | as the last argument. The optional @var{super-invocation-arguments} is |
---|
670 | a list of numbers between 1 and @code{(length argument-types)}, where |
---|
671 | the number @var{k} stands for the @var{k}th argument to the just |
---|
672 | defined constructor. If present, the constructor of the superclass |
---|
673 | will be called with the appropriate arguments. E.g., if the |
---|
674 | constructor definition is @code{(("java.lang.String" "int") #'(lambda |
---|
675 | (string i this) ...) (2 1))} then the constructor of the superclass |
---|
676 | with argument types @code{(int, java.lang.String)} will be called with |
---|
677 | the second and first arguments. |
---|
678 | |
---|
679 | Method definitions are lists of the form @code{(method-name |
---|
680 | return-type argument-types function &key modifiers annotations)} where |
---|
681 | @var{method-name} is a string, @var{return-type} and |
---|
682 | @var{argument-types} are strings or keywords for primitive types |
---|
683 | (@code{:void}, @code{:int}, etc.), and @var{function} is a Lisp |
---|
684 | function of minimum arity @code{(1+ (length argument-types))}; the |
---|
685 | instance (@code{this}) is passed in as the first argument. |
---|
686 | |
---|
687 | Field definitions are lists of the form @code{(field-name type &key |
---|
688 | modifiers annotations)}. |
---|
689 | @end defun |
---|
690 | |
---|
691 | |
---|
692 | @node Calling from Java to Lisp |
---|
693 | @section Calling from Java to Lisp |
---|
694 | |
---|
695 | This section describes the various ways that one interacts with Lisp |
---|
696 | from Java code. In order to access the Lisp world from Java, one needs |
---|
697 | to be aware of a few things, the most important ones being listed below: |
---|
698 | |
---|
699 | @itemize |
---|
700 | @item |
---|
701 | All Lisp values are descendants of @code{LispObject}. |
---|
702 | |
---|
703 | @item |
---|
704 | Lisp symbols are accessible either via static members of the |
---|
705 | @code{Symbol} class, or by dynamically introspecting a @code{Package} |
---|
706 | object. |
---|
707 | |
---|
708 | @item |
---|
709 | The Lisp dynamic environment may be saved via |
---|
710 | @code{LispThread.bindSpecial(Binding)} and restored via |
---|
711 | @code{LispThread.resetSpecialBindings(Mark)}. |
---|
712 | |
---|
713 | @item |
---|
714 | Functions can be executed by invoking @code{LispObject.execute(args |
---|
715 | [...])} |
---|
716 | |
---|
717 | @end itemize |
---|
718 | |
---|
719 | |
---|
720 | @menu |
---|
721 | * Acquiring an Interpreter Object:: |
---|
722 | * Evaluating Lisp Forms:: |
---|
723 | * Calling Common Lisp Functions Directly:: |
---|
724 | * Introspecting a Lisp Object:: |
---|
725 | @end menu |
---|
726 | |
---|
727 | @node Acquiring an Interpreter Object |
---|
728 | @subsection Acquiring an Interpreter Object |
---|
729 | |
---|
730 | The entire ABCL Lisp system resides in the |
---|
731 | @code{org.armedbear.lisp} package, but the following code snippets do |
---|
732 | not show the relevant import statements in the interest of brevity. An |
---|
733 | example of the import statement would be |
---|
734 | @example |
---|
735 | import org.armedbear.lisp.*; |
---|
736 | @end example |
---|
737 | to potentially import all the JVM symbol from the |
---|
738 | @code{org.armedbear.lisp} namespace. |
---|
739 | |
---|
740 | There can only ever be a single Lisp interpreter per JVM instance. A |
---|
741 | reference to this interpreter is obtained by calling the static method |
---|
742 | @code{Interpreter.createInstance()}. |
---|
743 | |
---|
744 | @example |
---|
745 | Interpreter interpreter = Interpreter.createInstance(); |
---|
746 | @end example |
---|
747 | |
---|
748 | If this method has already been invoked in the lifetime of the current |
---|
749 | Java process it will return @code{null}, so if you are writing Java |
---|
750 | whose life-cycle is a bit out of your control (like in a Java servlet), |
---|
751 | a safer invocation pattern might be: |
---|
752 | |
---|
753 | @example |
---|
754 | Interpreter interpreter = Interpreter.getInstance(); |
---|
755 | if (interpreter == null) @{ |
---|
756 | interpreter = Interpreter.createInstance(); |
---|
757 | @} |
---|
758 | @end example |
---|
759 | |
---|
760 | |
---|
761 | @node Evaluating Lisp Forms |
---|
762 | @subsection Evaluating Lisp Forms |
---|
763 | |
---|
764 | The Lisp @code{eval} primitive may simply be passed strings for |
---|
765 | evaluation: |
---|
766 | |
---|
767 | @example |
---|
768 | String line = "(load \"file.lisp\")"; |
---|
769 | LispObject result = interpreter.eval(line); |
---|
770 | @end example |
---|
771 | |
---|
772 | Notice that all possible return values from an arbitrary Lisp |
---|
773 | computation are collapsed into a single return value. Doing useful |
---|
774 | further computation on the @code{LispObject} depends on knowing what the |
---|
775 | result of the computation might be. This usually involves some amount |
---|
776 | of @code{instanceof} introspection, and forms a whole topic to itself |
---|
777 | (@pxref{Introspecting a Lisp Object}). |
---|
778 | |
---|
779 | Using @code{eval} involves the Lisp interpreter. Lisp functions may |
---|
780 | also be directly invoked by Java method calls as follows. One simply |
---|
781 | locates the package containing the symbol, obtains a reference to the |
---|
782 | symbol, and then invokes the @code{execute()} method with the desired |
---|
783 | parameters. |
---|
784 | |
---|
785 | @example |
---|
786 | interpreter.eval("(defun foo (msg)" + |
---|
787 | "(format nil \"You told me '~A'~%\" msg))"); |
---|
788 | Package pkg = Packages.findPackage("CL-USER"); |
---|
789 | Symbol foo = pkg.findAccessibleSymbol("FOO"); |
---|
790 | Function fooFunction = (Function)foo.getSymbolFunction(); |
---|
791 | JavaObject parameter = new JavaObject("Lisp is fun!"); |
---|
792 | LispObject result = fooFunction.execute(parameter); |
---|
793 | // How to get the "naked string value"? |
---|
794 | System.out.println("The result was " + result.writeToString()); |
---|
795 | @end example |
---|
796 | |
---|
797 | |
---|
798 | @node Calling Common Lisp Functions Directly |
---|
799 | @subsection Calling Common Lisp Functions Directly |
---|
800 | |
---|
801 | If one is calling a function in the @var{CL} package, the syntax can |
---|
802 | become considerably simpler. If we can locate the instance of |
---|
803 | definition in the ABCL Java source, we can invoke the symbol directly. |
---|
804 | For instance, to tell if a @code{LispObject} is (Lisp) @code{NIL}, we |
---|
805 | can invoke the CL function @code{NULL} in the following way: |
---|
806 | |
---|
807 | @example |
---|
808 | boolean nullp(LispObject object) @{ |
---|
809 | LispObject result = Primitives.NULL.execute(object); |
---|
810 | if (result == NIL) @{ // the symbol 'NIL' is explicitly named in the Java |
---|
811 | // namespace at ``Symbol.NIL'' |
---|
812 | // but is always present in the |
---|
813 | // local namespace in its unadorned form for |
---|
814 | // the convenience of the User. |
---|
815 | return false; |
---|
816 | @} |
---|
817 | return true; |
---|
818 | @} |
---|
819 | @end example |
---|
820 | |
---|
821 | |
---|
822 | @node Introspecting a Lisp Object |
---|
823 | @subsection Introspecting a Lisp Object |
---|
824 | |
---|
825 | We present various patterns for introspecting an arbitrary |
---|
826 | @code{LispObject} which can hold the result of every Lisp evaluation |
---|
827 | into semantics that Java can meaningfully deal with. |
---|
828 | |
---|
829 | |
---|
830 | @menu |
---|
831 | * LispObject as boolean:: |
---|
832 | * LispObject as a list:: |
---|
833 | @end menu |
---|
834 | |
---|
835 | @node LispObject as boolean |
---|
836 | @subsubsection LispObject as @code{boolean} |
---|
837 | |
---|
838 | If the @code{LispObject} is to be interpreted as a generalized boolean |
---|
839 | value, one can use @code{getBooleanValue()} to convert to Java: |
---|
840 | |
---|
841 | @example |
---|
842 | LispObject object = Symbol.NIL; |
---|
843 | boolean javaValue = object.getBooleanValue(); |
---|
844 | @end example |
---|
845 | |
---|
846 | Since in Lisp any value other than @code{NIL} means "true", Java |
---|
847 | equality can also be used, which is a bit easier to type and better in |
---|
848 | terms of information it conveys to the compiler: |
---|
849 | |
---|
850 | @example |
---|
851 | boolean javaValue = (object != Symbol.NIL); |
---|
852 | @end example |
---|
853 | |
---|
854 | |
---|
855 | @node LispObject as a list |
---|
856 | @subsubsection LispObject as a list |
---|
857 | |
---|
858 | If @code{LispObject} is a list, it will have the Java type @code{Cons}. |
---|
859 | One can then use the @code{copyToArray} method to make things a bit more |
---|
860 | suitable for Java iteration. |
---|
861 | |
---|
862 | @example |
---|
863 | LispObject result = interpreter.eval("'(1 2 4 5)"); |
---|
864 | if (result instanceof Cons) @{ |
---|
865 | LispObject array[] = ((Cons)result.copyToArray()); |
---|
866 | ... |
---|
867 | @} |
---|
868 | @end example |
---|
869 | |
---|
870 | A more Lispy way to iterate down a list is to use the @code{cdr()} |
---|
871 | access function just as like one would traverse a list in Lisp:; |
---|
872 | |
---|
873 | @example |
---|
874 | LispObject result = interpreter.eval("'(1 2 4 5)"); |
---|
875 | while (result != Symbol.NIL) @{ |
---|
876 | doSomething(result.car()); |
---|
877 | result = result.cdr(); |
---|
878 | @} |
---|
879 | @end example |
---|
880 | |
---|
881 | |
---|
882 | @node Java Scripting API (JSR-223) |
---|
883 | @section Java Scripting API (JSR-223) |
---|
884 | |
---|
885 | ABCL can be built with support for JSR-223, which offers a |
---|
886 | language-agnostic API to invoke other languages from Java. The binary |
---|
887 | distribution from ABCL's homepage is built with JSR-223 support. If you |
---|
888 | are building ABCL from source on a pre-1.6 JVM, you need to have a |
---|
889 | JSR-223 implementation in your classpath (such as Apache Commons BSF 3.x |
---|
890 | or greater) in order to build ABCL with JSR-223 support; otherwise, this |
---|
891 | feature will not be built. |
---|
892 | |
---|
893 | This section describes the design decisions behind the ABCL JSR-223 |
---|
894 | support. It is not a description of what JSR-223 is or a tutorial on how |
---|
895 | to use it. See |
---|
896 | @url{http://abcl.org/svn/trunk/abcl/examples/jsr-223} |
---|
897 | for example usage. |
---|
898 | |
---|
899 | |
---|
900 | @menu |
---|
901 | * Conversions:: |
---|
902 | * Implemented JSR-223 interfaces:: |
---|
903 | * Start-up and configuration file:: |
---|
904 | * Evaluation:: |
---|
905 | * Compilation:: |
---|
906 | * Invocation of functions and methods:: |
---|
907 | * Creating Lisp interface proxies:: |
---|
908 | @end menu |
---|
909 | |
---|
910 | @node Conversions |
---|
911 | @subsection Conversions |
---|
912 | |
---|
913 | In general, ABCL's implementation of the JSR-223 API performs implicit |
---|
914 | conversion from Java objects to Lisp objects when invoking Lisp from |
---|
915 | Java, and the opposite when returning values from Java to Lisp. This |
---|
916 | potentially reduces coupling between user code and ABCL. To avoid such |
---|
917 | conversions, wrap the relevant objects in @code{JavaObject} instances. |
---|
918 | |
---|
919 | |
---|
920 | @node Implemented JSR-223 interfaces |
---|
921 | @subsection Implemented JSR-223 interfaces |
---|
922 | |
---|
923 | JSR-223 defines three main interfaces, of which two (@code{Invocable} |
---|
924 | and @code{Compilable}) are optional. ABCL implements all three |
---|
925 | interfaces - @code{ScriptEngine} and the two optional ones - almost |
---|
926 | completely. While the JSR-223 API is not specific to a single scripting |
---|
927 | language, it was designed with languages with a more or less Java-like |
---|
928 | object model in mind: languages such as Javascript, Python, Ruby, which |
---|
929 | have a concept of "class" or "object" with "fields" and "methods". Lisp |
---|
930 | is a bit different, so certain adaptations were made, and in one case a |
---|
931 | method has been left unimplemented since it does not map at all to Lisp. |
---|
932 | |
---|
933 | |
---|
934 | @menu |
---|
935 | * The ScriptEngine object:: |
---|
936 | @end menu |
---|
937 | |
---|
938 | @node The ScriptEngine object |
---|
939 | @subsubsection The ScriptEngine object |
---|
940 | |
---|
941 | The main interface defined by JSR-223, @code{javax.script.ScriptEngine}, |
---|
942 | is implemented by the class |
---|
943 | @code{org.armedbear.lisp.scripting.AbclScriptEngine}. @code{AbclScriptEngine} |
---|
944 | is a singleton, reflecting the fact that ABCL is a singleton as |
---|
945 | well. You can obtain an instance of @code{AbclScriptEngine} using |
---|
946 | @code{AbclScriptEngineFactory} or by using the service provider |
---|
947 | mechanism through @code{ScriptEngineManager} (refer to the |
---|
948 | @code{javax.script} documentation). |
---|
949 | |
---|
950 | |
---|
951 | @node Start-up and configuration file |
---|
952 | @subsection Start-up and configuration file |
---|
953 | |
---|
954 | At start-up (i.e. when its constructor is invoked, as part of the static |
---|
955 | initialization phase of @code{AbclScriptEngineFactory}), the ABCL script |
---|
956 | engine attempts to load an "init file" from the classpath |
---|
957 | (@file{/abcl-script-config.lisp}). If present, this file can be used to |
---|
958 | customize the behavior of the engine, by setting a number of variables |
---|
959 | in the @code{ABCL-SCRIPT} package. Here is a list of the available |
---|
960 | variables: |
---|
961 | |
---|
962 | @defvar @earmuffs{use-throwing-debugger} |
---|
963 | controls whether ABCL uses a non-standard debugging hook function to |
---|
964 | throw a Java exception instead of dropping into the debugger in case of |
---|
965 | unhandled error conditions. |
---|
966 | |
---|
967 | Its default value is @code{T}, since it is more convenient for Java |
---|
968 | programmers using Lisp as a scripting language to have it return |
---|
969 | exceptions to Java instead of handling them in the Lisp world. |
---|
970 | |
---|
971 | Known issues: the non-standard debugger hook has been reported to |
---|
972 | misbehave in certain circumstances, so consider disabling it if it |
---|
973 | doesn't work for you. |
---|
974 | @end defvar |
---|
975 | |
---|
976 | @defvar @earmuffs{launch-swank-at-startup} |
---|
977 | If true, Swank will be launched at startup. See @code{*swank-dir*} and |
---|
978 | @code{*swank-port*}. Default value: @code{NIL}. |
---|
979 | @end defvar |
---|
980 | |
---|
981 | @defvar @earmuffs{swank-dir} |
---|
982 | The directory where Swank is installed. Must be set if |
---|
983 | @code{*launch-swank-at-startup*} is true. |
---|
984 | @end defvar |
---|
985 | |
---|
986 | @defvar @earmuffs{swank-port} |
---|
987 | The port where Swank will listen for connections. Must be set if |
---|
988 | @code{*launch-swank-at-startup*} is true. Default value: 4005 |
---|
989 | @end defvar |
---|
990 | |
---|
991 | Additionally, at startup the @code{AbclScriptEngine} will execute |
---|
992 | @code{(require 'asdf)} - in fact, it uses asdf to load Swank. |
---|
993 | |
---|
994 | |
---|
995 | @node Evaluation |
---|
996 | @subsection Evaluation |
---|
997 | |
---|
998 | Code is read and evaluated in the package @code{ABCL-SCRIPT-USER}. This |
---|
999 | package uses the @code{COMMON-LISP}, @code{JAVA} and @code{ABCL-SCRIPT} |
---|
1000 | packages. Future versions of the script engine might make thisf default |
---|
1001 | package configurable. The @code{CL:LOAD} function is used under the hood |
---|
1002 | for evaluating code, and thus the behavior of @code{LOAD} is |
---|
1003 | guaranteed. This allows, among other things, @code{IN-PACKAGE} forms to |
---|
1004 | change the package in which the loaded code is read. |
---|
1005 | |
---|
1006 | It is possible to evaluate code in what JSR-223 calls a |
---|
1007 | ``ScriptContext'' (basically a flat environment of name-to-value |
---|
1008 | pairs). This context is used to establish special bindings for all the |
---|
1009 | variables defined in it; since variable names are strings from Java's |
---|
1010 | point of view, they are first interned using @code{READ-FROM-STRING} |
---|
1011 | with, as usual, @code{ABCL-SCRIPT-USER} as the default |
---|
1012 | package. Variables are declared special because CL's @code{LOAD}, |
---|
1013 | @code{EVAL} and @code{COMPILE} functions work in a null lexical |
---|
1014 | environment and would ignore non-special bindings. |
---|
1015 | |
---|
1016 | Contrary to what the function @code{LOAD} does, evaluation of a series |
---|
1017 | of forms returns the value of the last form instead of @code{T}, so the |
---|
1018 | evaluation of short scripts does the Right Thing. |
---|
1019 | |
---|
1020 | |
---|
1021 | @node Compilation |
---|
1022 | @subsection Compilation |
---|
1023 | |
---|
1024 | @code{AbclScriptEngine} implements the @code{javax.script.Compilable} |
---|
1025 | interface. Currently it only supports compilation using temporary |
---|
1026 | files. Compiled code, returned as an instance of |
---|
1027 | @code{javax.script.CompiledScript}, is read, compiled and executed by |
---|
1028 | default in the @code{ABCL-SCRIPT-USER} package, just like evaluated |
---|
1029 | code. In contrast to evaluated code, though, due to the way the ABCL |
---|
1030 | compiler works, compiled code contains no reference to top-level |
---|
1031 | self-evaluating objects (like numbers or strings). Thus, when evaluated, |
---|
1032 | a piece of compiled code will return the value of the last |
---|
1033 | non-self-evaluating form: for example the code @code{(do-something) 42} |
---|
1034 | will return 42 when interpreted, but will return the result of |
---|
1035 | @code{(do-something)} when compiled and later executed. To ensure |
---|
1036 | consistency of behavior between interpreted and compiled code, make sure |
---|
1037 | the last form is always a compound form -- at least @code{(identity |
---|
1038 | some-literal-object)}. Note that this issue should not matter in real |
---|
1039 | code, where it is unlikely a top-level self-evaluating form will appear |
---|
1040 | as the last form in a file (in fact, the Common Lisp load function |
---|
1041 | always returns @code{T} upon success; with JSR-223 this policy has |
---|
1042 | been changed to make evaluation of small code snippets work as |
---|
1043 | intended). |
---|
1044 | |
---|
1045 | |
---|
1046 | @node Invocation of functions and methods |
---|
1047 | @subsection Invocation of functions and methods |
---|
1048 | |
---|
1049 | @code{AbclScriptEngine} implements the @code{javax.script.Invocable} |
---|
1050 | interface, which allows to directly call Lisp functions and methods, and |
---|
1051 | to obtain Lisp implementations of Java interfaces. This is only |
---|
1052 | partially possible with Lisp since it has functions, but not methods -- |
---|
1053 | not in the traditional OO sense, at least, since Lisp methods belong to |
---|
1054 | generic functions. Thus, the method @code{invokeMethod()} is not |
---|
1055 | implemented and throws an @code{UnsupportedOperationException} when |
---|
1056 | called. The @code{invokeFunction()} method is used to call both regular |
---|
1057 | and generic functions. |
---|
1058 | |
---|
1059 | |
---|
1060 | @node Creating Lisp interface proxies |
---|
1061 | @subsection Creating Lisp interface proxies |
---|
1062 | |
---|
1063 | The functionality of @code{jmake-proxy} is exposed by the class |
---|
1064 | @code{AbclScriptEngine} via the two methods @code{getInterface(Class)} |
---|
1065 | and @code{getInterface(Object, Class)}. The former returns an interface |
---|
1066 | implemented with the current Lisp package, the latter allows the |
---|
1067 | programmer to pass an interface-implementation object which will in turn |
---|
1068 | be passed to the @code{jmake-proxy} generic function. |
---|
1069 | |
---|
1070 | |
---|
1071 | |
---|
1072 | |
---|
1073 | @node Implementation Dependent Extensions |
---|
1074 | @chapter Implementation Dependent Extensions |
---|
1075 | |
---|
1076 | As outlined by the CLHS ANSI conformance guidelines, we document the |
---|
1077 | extensions to the Armed Bear Lisp implementation made accessible to the |
---|
1078 | user by virtue of being an exported symbol in the @code{JAVA}, |
---|
1079 | @code{THREADS}, or @code{EXTENSIONS} packages. |
---|
1080 | |
---|
1081 | |
---|
1082 | @menu |
---|
1083 | * Extensions in the JAVA package:: |
---|
1084 | * Extensions in the THREADS package:: |
---|
1085 | * Extensions in the EXT package:: |
---|
1086 | @end menu |
---|
1087 | |
---|
1088 | @node Extensions in the JAVA package |
---|
1089 | @section Extensions in the JAVA package |
---|
1090 | |
---|
1091 | @c % include autogen docs for the JAVA package. |
---|
1092 | @c \include{java} |
---|
1093 | |
---|
1094 | @node Extensions in the THREADS package |
---|
1095 | @section Extensions in the THREADS package |
---|
1096 | |
---|
1097 | The extensions for handling multithreaded execution are collected in |
---|
1098 | the @code{THREADS} package. Most of the abstractions in Doug Lea's |
---|
1099 | excellent @code{java.util.concurrent} packages may be manipulated |
---|
1100 | directly via the JSS contrib to great effect. |
---|
1101 | |
---|
1102 | @c % include autogen docs for the THREADS package. |
---|
1103 | @c \include{threads} |
---|
1104 | |
---|
1105 | @node Extensions in the EXT package |
---|
1106 | @section Extensions in the EXT package |
---|
1107 | |
---|
1108 | The symbols in the @code{EXTENSIONS} package (nicknamed @code{EXT}) |
---|
1109 | constitutes extensions to the ANSI standard that are |
---|
1110 | potentially useful to the user. They include functions for manipulating |
---|
1111 | network sockets, running external programs, registering object |
---|
1112 | finalizers, constructing reference weakly held by the garbage collector |
---|
1113 | and others. |
---|
1114 | |
---|
1115 | For a generic function interface to the native JVM contract for |
---|
1116 | @code{java.util.List}, @pxref{Extensible Sequences}. |
---|
1117 | |
---|
1118 | @c % include autogen docs for the EXTENSIONS package. |
---|
1119 | @c \include{extensions} |
---|
1120 | |
---|
1121 | @node Beyond ANSI |
---|
1122 | @chapter Beyond ANSI |
---|
1123 | |
---|
1124 | Naturally, in striving to be a useful contemporary Common Lisp |
---|
1125 | implementation, ABCL endeavors to include extensions beyond the ANSI |
---|
1126 | specification which are either widely adopted or are especially useful |
---|
1127 | in working with the hosting JVM. |
---|
1128 | |
---|
1129 | @menu |
---|
1130 | * Modifying the JVM Classpath:: |
---|
1131 | * Compiler to Java 5 Bytecode:: |
---|
1132 | * Pathnames:: |
---|
1133 | * Extensible Sequences:: |
---|
1134 | * Extensions to CLOS:: |
---|
1135 | * Extensions to the Reader:: |
---|
1136 | * Overloading of the REQUIRE Mechanism:: |
---|
1137 | * JSS optionally extends the Reader:: |
---|
1138 | * ASDF:: |
---|
1139 | @end menu |
---|
1140 | |
---|
1141 | @node Modifying the JVM Classpath |
---|
1142 | @section Modifying the JVM Classpath |
---|
1143 | |
---|
1144 | @deffn {Generic Function} add-to-classpath jar-or-jars @ |
---|
1145 | &optional classloader |
---|
1146 | |
---|
1147 | The @code{add-to-classpath} generic functions allows one to add a |
---|
1148 | pathname or list of pathnames to the current classpath used by ABCL, |
---|
1149 | allowing the dynamic loading of JVM objects: |
---|
1150 | |
---|
1151 | @lisp |
---|
1152 | (add-to-classpath "/path/to/some.jar") |
---|
1153 | @end lisp |
---|
1154 | |
---|
1155 | N.b @code{add-to-classpath} only affects the classloader used by ABCL |
---|
1156 | (the value of the special variable @code{java::*classloader*}). It has |
---|
1157 | no effect on Java code outside ABCL. |
---|
1158 | @end deffn |
---|
1159 | |
---|
1160 | @node Compiler to Java 5 Bytecode |
---|
1161 | @section Compiler to Java 5 Bytecode |
---|
1162 | |
---|
1163 | The @code{CL:COMPILE-FILE} interface emits a packed fasl format whose |
---|
1164 | Pathname has the type @file{abcl}. These fasls are operating system |
---|
1165 | neutral byte archives packaged by the zip compression format which |
---|
1166 | contain artifacts that are understood by @code{CL:LOAD}. |
---|
1167 | |
---|
1168 | @node Pathnames |
---|
1169 | @section Pathnames |
---|
1170 | |
---|
1171 | We implement an extension to the @code{CL:PATHNAME} that allows for the |
---|
1172 | description and retrieval of resources named in a URI@footnote{A |
---|
1173 | URI is essentially a superset of what is commonly understood as a |
---|
1174 | URL. We sometimes use the term URL as shorthand in describing the |
---|
1175 | URL Pathnames, even though the corresponding encoding is more akin to a |
---|
1176 | URI as described in RFC3986.} scheme that the JVM ``understands''. By |
---|
1177 | definition, support is built-in into the JVM to access the |
---|
1178 | @code{http://} and @code{https://} schemes but additional protocol |
---|
1179 | handlers may be installed at runtime by having JVM symbols present |
---|
1180 | in the @code{sun.net.protocol.dynamic} package (see |
---|
1181 | @url{http://java.sun.com/developer/onlineTraining/protocolhandlers/} for |
---|
1182 | more details). |
---|
1183 | |
---|
1184 | ABCL has created specializations of the ANSI @code{PATHNAME} object to |
---|
1185 | enable to use of URIs to address dynamically loaded resources for |
---|
1186 | the JVM. The @code{EXT:URL-PATHNAME} specialization has a corresponding |
---|
1187 | URI whose canonical representation is defined to be the |
---|
1188 | @code{NAMESTRING} of the Pathname. The @code{EXT:JAR-PATHNAME} extension |
---|
1189 | further specializes the the @code{EXT:URL-PATHNAME} to provide access to |
---|
1190 | components of zip and jar archives. |
---|
1191 | |
---|
1192 | @c % RDF description of type hierarchy |
---|
1193 | @c % TODO Render via some LaTeX mode for graphviz? |
---|
1194 | @example |
---|
1195 | @@prefix ext: <http://abcl.not.org/cl-packages/extensions/> . |
---|
1196 | @@prefix cl: <http://abcl.not.org/cl-pacages/common-lisp/> . |
---|
1197 | |
---|
1198 | <ext:jar-pathname> a <ext:url-pathname>. |
---|
1199 | <ext:url-pathname> a <cl:pathname>. |
---|
1200 | <cl:logical-pathname> a <cl:pathname> . |
---|
1201 | @end example |
---|
1202 | |
---|
1203 | @deftp {Built-In Class} url-pathname |
---|
1204 | @deftpx {Built-In Class} jar-pathname |
---|
1205 | |
---|
1206 | @code{url-pathname} and @code{jar-pathname} are subclasses of the |
---|
1207 | @code{pathname} built-in class. Objects of type |
---|
1208 | @code{Ext:url-pathname} and @code{ext:jar-pathname} may be used |
---|
1209 | anywhere a @code{cl:pathname} is accepted with the following caveats: |
---|
1210 | |
---|
1211 | @itemize |
---|
1212 | @item |
---|
1213 | A stream obtained via @code{cl:open} on a @code{ext:url-pathname} cannot |
---|
1214 | be the target of write operations. |
---|
1215 | |
---|
1216 | @item |
---|
1217 | Any results of canonicalization procesures performed on the underlying |
---|
1218 | URI are discarded between resolutions (i.e. the implementation does not |
---|
1219 | attempt to cache the results of current name resolution of the |
---|
1220 | representing resource unless it is requested to be resolved). Upon |
---|
1221 | resolution, any canoicalization procedures followed in resolving the |
---|
1222 | resource (e.g., following redirects) are discarded. Users may |
---|
1223 | programatically initiate a new, local computation by applying the |
---|
1224 | @code{cl:truename} function to a @code{ext:url-pathname} object. |
---|
1225 | Depending on the reliablity and properties of your local REST |
---|
1226 | infrastructure, these results may not necessarily be idempotent over |
---|
1227 | time.@footnote {See |
---|
1228 | @url{http://code.google.com/p/abcl-dynamic-install/source/browse/doc/design/pathnames/pathnames.tex} |
---|
1229 | for the draft of the publication of the technical details} |
---|
1230 | @end itemize |
---|
1231 | |
---|
1232 | @end deftp |
---|
1233 | |
---|
1234 | The implementation of @code{ext:url-pathname} allows the ABCL user to |
---|
1235 | dynamically load code from the network. For example, Quicklisp may be |
---|
1236 | completely installed from the REPL as the single form: |
---|
1237 | |
---|
1238 | @lisp |
---|
1239 | CL-USER> (load "http://beta.quicklisp.org/quicklisp.lisp") |
---|
1240 | @end lisp |
---|
1241 | |
---|
1242 | The implementation currently breaks ANSI conformance by allowing the |
---|
1243 | types able to be @code{cl:read} for the @var{device} to return a |
---|
1244 | possible @code{cons} of @code{cl:pathname} objects. |
---|
1245 | @c %% citation from CLHS needed. |
---|
1246 | |
---|
1247 | In order to ``smooth over'' the bit about types being @code{cl:read} from |
---|
1248 | @code{cl:pathname} components, we extend the semantics for the usual PATHNAME |
---|
1249 | merge semantics when @code{*default-pathname-defaults*} contains a |
---|
1250 | @code{ext:jar-pathname}. |
---|
1251 | |
---|
1252 | @menu |
---|
1253 | * Implementation of Pathname Extensions:: |
---|
1254 | @end menu |
---|
1255 | |
---|
1256 | @node Implementation of Pathname Extensions |
---|
1257 | @subsection Implementation of Pathname Extensions |
---|
1258 | |
---|
1259 | The implementation of these extensions stores all the additional |
---|
1260 | information in the @code{CL:PATHNAME} object itself in ways that while |
---|
1261 | strictly speaking are conformant, nonetheless may trip up libraries that |
---|
1262 | don't expect the following: |
---|
1263 | |
---|
1264 | @itemize |
---|
1265 | @item |
---|
1266 | @code{DEVICE} can be either a string denoting a drive letter under DOS, |
---|
1267 | or a list of exactly one or two elements. If @code{DEVICE} is a list, |
---|
1268 | it denotes a @code{EXT:JAR-PATHNAME}, with the entries containing |
---|
1269 | @code{CL:PATHNAME} objects which describe the outer and (possibly inner) |
---|
1270 | locations of the jar archive.@footnote{The case of inner and outer |
---|
1271 | @code{EXT:EJAR-PATHNAME} arises when zip archives themselves contain zip |
---|
1272 | archives, which is the case when the ABCL fasl is included in the |
---|
1273 | @file{abcl.jar} zip archive.} |
---|
1274 | |
---|
1275 | @item |
---|
1276 | An @code{EXT:URL-PATHNAME} always has a @code{HOST} component that is a |
---|
1277 | property list. The values of the @code{HOST} property list are always |
---|
1278 | character strings. The allowed keys have the following meanings: |
---|
1279 | |
---|
1280 | @table @code |
---|
1281 | |
---|
1282 | @item :SCHEME |
---|
1283 | Scheme of URI ("http", "ftp", "bundle", etc.) |
---|
1284 | |
---|
1285 | @item :AUTHORITY |
---|
1286 | Valid authority according to the URI scheme. For "http" this could be |
---|
1287 | "example.org:8080". |
---|
1288 | |
---|
1289 | @item :QUERY |
---|
1290 | The query portion of the URI |
---|
1291 | |
---|
1292 | @item :FRAGMENT |
---|
1293 | The fragment portion of the URI |
---|
1294 | @end table |
---|
1295 | @end itemize |
---|
1296 | |
---|
1297 | In order to encapsulate the implementation decisions for these meanings, |
---|
1298 | the following functions provide a @code{setf}-able API for reading and writing |
---|
1299 | such values. |
---|
1300 | |
---|
1301 | @deffn {Accessor} url-pathname-scheme |
---|
1302 | @deffnx {Accessor} url-pathname-fragment |
---|
1303 | @deffnx {Accessor} url-pathname-authority |
---|
1304 | @deffnx {Accessor} url-pathname-query |
---|
1305 | These functions and their @code{setf} form provide read and write |
---|
1306 | access to the components of a @code{url-pathname} object. |
---|
1307 | @end deffn |
---|
1308 | |
---|
1309 | The specific subtype of a Pathname may be determined with the predicates |
---|
1310 | @code{pathname-url-p} and @code{pathname-jar-p}. |
---|
1311 | |
---|
1312 | @defun pathname-url-p object |
---|
1313 | @defunx pathname-jar-p object |
---|
1314 | These predicates return @code{T} if @var{object} is a designator for a |
---|
1315 | pathname of the specific type. E.g.: |
---|
1316 | @lisp |
---|
1317 | (pathname-url-p "http://google.com/") |
---|
1318 | @result{} T |
---|
1319 | @end lisp |
---|
1320 | @end defun |
---|
1321 | |
---|
1322 | @node Package-Local Nicknames |
---|
1323 | @section Package-Local Nicknames |
---|
1324 | |
---|
1325 | ABCL allows giving packages local nicknames: they allow short and |
---|
1326 | easy-to-use names to be used without fear of name conflict associated |
---|
1327 | with normal nicknames.@footnote{Package-local nicknames were originally |
---|
1328 | developed in SBCL.} |
---|
1329 | |
---|
1330 | A local nickname is valid only when inside the package for which it |
---|
1331 | has been specified. Different packages can use same local nickname for |
---|
1332 | different global names, or different local nickname for same global |
---|
1333 | name. |
---|
1334 | |
---|
1335 | Symbol @code{:package-local-nicknames} in @code{*features*} denotes the |
---|
1336 | support for this feature. |
---|
1337 | |
---|
1338 | @defmac defpackage name [[option]]* @result{} package |
---|
1339 | |
---|
1340 | Options are extended to include |
---|
1341 | |
---|
1342 | @itemize |
---|
1343 | @item |
---|
1344 | @code{:local-nicknames} @var{(local-nickname actual-package-name)}* |
---|
1345 | |
---|
1346 | The package has the specified local nicknames for the corresponding |
---|
1347 | actual packages. |
---|
1348 | @end itemize |
---|
1349 | |
---|
1350 | Example: |
---|
1351 | |
---|
1352 | @lisp |
---|
1353 | (defpackage :bar (:intern "X")) |
---|
1354 | (defpackage :foo (:intern "X")) |
---|
1355 | (defpackage :quux (:use :cl) (:local-nicknames (:bar :foo) (:foo :bar))) |
---|
1356 | (find-symbol "X" :foo) ; => FOO::X |
---|
1357 | (find-symbol "X" :bar) ; => BAR::X |
---|
1358 | (let ((*package* (find-package :quux))) |
---|
1359 | (find-symbol "X" :foo)) ; => BAR::X |
---|
1360 | (let ((*package* (find-package :quux))) |
---|
1361 | (find-symbol "X" :bar)) ; => FOO::X |
---|
1362 | @end lisp |
---|
1363 | @end defmac |
---|
1364 | |
---|
1365 | @defun package-local-nicknames (package-designator) |
---|
1366 | |
---|
1367 | Returns an alist of (local-nickname . actual-package) describing the |
---|
1368 | nicknames local to the designated package. |
---|
1369 | |
---|
1370 | When in the designated package, calls to @code{find-package} with any of |
---|
1371 | the local-nicknames will return the corresponding actual-package |
---|
1372 | instead. This also affects all implied calls to @code{find-package}, |
---|
1373 | including those performed by the reader. |
---|
1374 | |
---|
1375 | When printing a package prefix for a symbol with a package local |
---|
1376 | nickname, the local nickname is used instead of the real name in order |
---|
1377 | to preserve print-read consistency. |
---|
1378 | @end defun |
---|
1379 | |
---|
1380 | @defun package-locally-nicknamed-by-list (package-designator) |
---|
1381 | |
---|
1382 | Returns a list of packages which have a local nickname for the |
---|
1383 | designated package. |
---|
1384 | @end defun |
---|
1385 | |
---|
1386 | @defun add-package-local-nickname (local-nickname actual-package &optional package-designator) |
---|
1387 | |
---|
1388 | Adds @code{local-nickname} for @code{actual-package} in the designated |
---|
1389 | package, defaulting to current package. @code{local-nickname} must be a |
---|
1390 | string designator, and @code{actual-package} must be a package |
---|
1391 | designator. |
---|
1392 | |
---|
1393 | Returns the designated package. |
---|
1394 | |
---|
1395 | Signals an error if @code{local-nickname} is already a package local |
---|
1396 | nickname for a different package, or if @code{local-nickname} is one of |
---|
1397 | "CL", "COMMON-LISP", or, "KEYWORD", or if @code{local-nickname} is a |
---|
1398 | global name or nickname for the package to which the nickname would be |
---|
1399 | added. |
---|
1400 | |
---|
1401 | When in the designated package, calls to @code{find-package} with the |
---|
1402 | @code{local-nickname} will return the package the designated |
---|
1403 | @code{actual-package} instead. This also affects all implied calls to |
---|
1404 | @code{find-package}, including those performed by the reader. |
---|
1405 | |
---|
1406 | When printing a package prefix for a symbol with a package local nickname, |
---|
1407 | local nickname is used instead of the real name in order to preserve |
---|
1408 | print-read consistency. |
---|
1409 | @end defun |
---|
1410 | |
---|
1411 | @defun remove-package-local-nickname (old-nickname &optional package-designator) |
---|
1412 | |
---|
1413 | If the designated package had @code{old-nickname} as a local nickname |
---|
1414 | for another package, it is removed. Returns true if the nickname existed |
---|
1415 | and was removed, and @code{nil} otherwise. |
---|
1416 | @end defun |
---|
1417 | |
---|
1418 | |
---|
1419 | @node Extensible Sequences |
---|
1420 | @section Extensible Sequences |
---|
1421 | |
---|
1422 | See |
---|
1423 | @url{http://doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdf} |
---|
1424 | for the design. |
---|
1425 | |
---|
1426 | The @code{SEQUENCE} package fully implements Christophe Rhodes' proposal |
---|
1427 | for extensible sequences. These user extensible sequences are used |
---|
1428 | directly in @code{java-collections.lisp} to provide these CLOS abstractions |
---|
1429 | on the standard Java collection classes as defined by the |
---|
1430 | @code{java.util.List} contract. |
---|
1431 | |
---|
1432 | @c %% an Example of using java.util.Lisp in Lisp would be nice |
---|
1433 | |
---|
1434 | This extension is not automatically loaded by the implementation. It |
---|
1435 | may be loaded via: |
---|
1436 | |
---|
1437 | @lisp |
---|
1438 | CL-USER> (require 'java-collections) |
---|
1439 | @end lisp |
---|
1440 | |
---|
1441 | if both extensible sequences and their application to Java collections |
---|
1442 | is required, or |
---|
1443 | |
---|
1444 | @lisp |
---|
1445 | CL-USER> (require 'extensible-sequences) |
---|
1446 | @end lisp |
---|
1447 | |
---|
1448 | if only the extensible sequences API is required. |
---|
1449 | |
---|
1450 | Note that @code{(require 'java-collections)} must be issued before |
---|
1451 | @code{java.util.List} or any subclass is used as a specializer in a CLOS |
---|
1452 | method definition (see the section below). |
---|
1453 | |
---|
1454 | @node Extensions to CLOS |
---|
1455 | @section Extensions to CLOS |
---|
1456 | |
---|
1457 | @menu |
---|
1458 | * Metaobject Protocol:: |
---|
1459 | * Specializing on Java classes:: |
---|
1460 | @end menu |
---|
1461 | |
---|
1462 | @node Metaobject Protocol |
---|
1463 | @subsection Metaobject Protocol |
---|
1464 | |
---|
1465 | ABCL implements the metaobject protocol for CLOS as specified in AMOP. |
---|
1466 | The symbols are exported from the package @code{MOP}. |
---|
1467 | |
---|
1468 | Contrary to the AMOP specification and following SBCL's lead, |
---|
1469 | the metaclass @code{funcallable-standard-object} has |
---|
1470 | @code{funcallable-standard-class} as metaclass instead of |
---|
1471 | @code{standard-class}. |
---|
1472 | |
---|
1473 | @node Specializing on Java classes |
---|
1474 | @subsection Specializing on Java classes |
---|
1475 | |
---|
1476 | There is an additional syntax for specializing the parameter of a |
---|
1477 | generic function on a java class, viz. @code{(java:jclass CLASS-STRING)} |
---|
1478 | where @code{CLASS-STRING} is a string naming a Java class in dotted package |
---|
1479 | form. |
---|
1480 | |
---|
1481 | For instance, the following specialization would perhaps allow one to |
---|
1482 | print more information about the contents of a |
---|
1483 | @code{java.util.Collection} object: |
---|
1484 | |
---|
1485 | @lisp |
---|
1486 | (defmethod print-object ((coll (java:jclass "java.util.Collection")) |
---|
1487 | stream) |
---|
1488 | ;;; ... |
---|
1489 | ) |
---|
1490 | @end lisp |
---|
1491 | |
---|
1492 | If the class had been loaded via a classloader other than the original |
---|
1493 | the class you wish to specialize on, one needs to specify the |
---|
1494 | classloader as an optional third argument. |
---|
1495 | |
---|
1496 | @lisp |
---|
1497 | (defparameter *other-classloader* |
---|
1498 | (jcall "getBaseLoader" cl-user::*classpath-manager*)) |
---|
1499 | |
---|
1500 | (defmethod print-object |
---|
1501 | ((device-id (java:jclass "dto.nbi.service.hdm.alcatel.com.NBIDeviceID" |
---|
1502 | *other-classloader*)) |
---|
1503 | stream) |
---|
1504 | ;;; ... |
---|
1505 | ) |
---|
1506 | @end lisp |
---|
1507 | |
---|
1508 | @node Extensions to the Reader |
---|
1509 | @section Extensions to the Reader |
---|
1510 | |
---|
1511 | We implement a special hexadecimal escape sequence for specifying 32-bit |
---|
1512 | characters to the Lisp reader,@footnote{This represents a compromise |
---|
1513 | with contemporary in 2011 32bit hosting architecures for which we wish |
---|
1514 | to make text processing efficient. Should the User require more control |
---|
1515 | over UNICODE processing we recommend Edi Weiz's excellent work with |
---|
1516 | FLEXI-STREAMS which we fully support} namely we allow a sequences of the |
---|
1517 | form @code{#\Uxxxx} to be processed by the reader as character whose |
---|
1518 | code is specified by the hexadecimal digits @code{xxxx}. The |
---|
1519 | hexadecimal sequence may be one to four digits long. |
---|
1520 | |
---|
1521 | Note that this sequence is never output by the implementation. Instead, |
---|
1522 | the corresponding Unicode character is output for characters whose |
---|
1523 | code is greater than @code{0x00ff}. |
---|
1524 | |
---|
1525 | @node Overloading of the REQUIRE Mechanism |
---|
1526 | @section Overloading of the CL:REQUIRE Mechanism |
---|
1527 | |
---|
1528 | The @code{CL:REQUIRE} mechanism is overloaded by attaching the following |
---|
1529 | semantic to the execution of @code{REQUIRE} on the following symbols: |
---|
1530 | |
---|
1531 | @table @code |
---|
1532 | @item ASDF |
---|
1533 | |
---|
1534 | Loads the ASDF implementation shipped with ABCL. After ASDF has been |
---|
1535 | loaded in this manner, symbols passed to @code{CL:REQUIRE} which are |
---|
1536 | otherwise unresolved are passed to ASDF for a chance for resolution. |
---|
1537 | This means, for instance, if @code{CL-PPCRE} can be located as a loadable |
---|
1538 | ASDF system, @code{(require 'cl-ppcre)} is equivalent to |
---|
1539 | @code{(asdf:load-system 'cl-ppcre)}. |
---|
1540 | |
---|
1541 | @item ABCL-CONTRIB |
---|
1542 | Locates and pushes the toplevel contents of @file{abcl-contrib.jar} into |
---|
1543 | the ASDF central registry, namely: |
---|
1544 | |
---|
1545 | @table @code |
---|
1546 | @item abcl-asdf |
---|
1547 | Functions for loading JVM artifacts dynamically, hooking into ASDF |
---|
1548 | objects where possible. @xref{abcl-asdf}. |
---|
1549 | |
---|
1550 | @item asdf-jar |
---|
1551 | Package addressable JVM artifacts via @code{abcl-asdf} descriptions |
---|
1552 | as a single binary artifact including recursive dependencies. |
---|
1553 | |
---|
1554 | @item mvn |
---|
1555 | |
---|
1556 | These systems name common JVM artifacts from the distributed pom.xml |
---|
1557 | graph of Maven Aether, at the moment @code{jna} dynamically loads |
---|
1558 | @code{jna.jar} version 3.5.1 from the network.@footnote{This loading |
---|
1559 | can be inhibited if, at runtime, the Java class corresponding |
---|
1560 | @code{:classname} clause of the system definition is present.} |
---|
1561 | |
---|
1562 | @end table |
---|
1563 | |
---|
1564 | @end table |
---|
1565 | |
---|
1566 | @defvar @earmuffs{module-provider-functions} |
---|
1567 | The user may extend the @code{cl:require} mechanism by pushing |
---|
1568 | function hooks onto this variable. Each such hook function must take |
---|
1569 | a single argument containing the symbol passed to @code{cl:require} |
---|
1570 | and return a non-@code{NIL} value if it successfully resolved the |
---|
1571 | symbol. |
---|
1572 | @end defvar |
---|
1573 | |
---|
1574 | @node JSS optionally extends the Reader |
---|
1575 | @section JSS optionally extends the Reader |
---|
1576 | |
---|
1577 | The JSS contrib consitutes an additional, optional extension to the |
---|
1578 | reader in the definition of the @code{SHARPSIGN-DOUBLE-QUOTE} |
---|
1579 | (@code{#"}) reader macro. @xref{JSS}. |
---|
1580 | |
---|
1581 | @node ASDF |
---|
1582 | @section ASDF |
---|
1583 | |
---|
1584 | ASDF is packaged as a core component of ABCL, but not initialized by |
---|
1585 | default as it relies on the CLOS subsystem which can take a bit of time |
---|
1586 | to start.@footnote{While this time is ``merely'' on the order of seconds |
---|
1587 | for contemporary 2011 machines, for applications that need to initialize |
---|
1588 | quickly, for example a web server, this time might be unnecessarily |
---|
1589 | long} The packaged ASDF may be loaded by the ANSI |
---|
1590 | @code{REQUIRE} mechanism as follows: |
---|
1591 | |
---|
1592 | @lisp |
---|
1593 | CL-USER> (require 'asdf) |
---|
1594 | @end lisp |
---|
1595 | |
---|
1596 | @node Contrib |
---|
1597 | @chapter Contrib |
---|
1598 | |
---|
1599 | The ABCL contrib is packaged as a separate jar archive usually named |
---|
1600 | @file{abcl-contrib.jar} or possibly something like |
---|
1601 | @file{abcl-contrib-1.1.0.jar}. The contrib jar is not loaded by the |
---|
1602 | implementation by default, and must be first intialized by the |
---|
1603 | @code{REQUIRE} mechanism before using any specific contrib: |
---|
1604 | |
---|
1605 | @lisp |
---|
1606 | CL-USER> (require 'abcl-contrib) |
---|
1607 | @end lisp |
---|
1608 | |
---|
1609 | @menu |
---|
1610 | * abcl-asdf:: |
---|
1611 | * asdf-jar:: |
---|
1612 | * JSS:: |
---|
1613 | * jfli:: |
---|
1614 | * asdf-install:: |
---|
1615 | @end menu |
---|
1616 | |
---|
1617 | @node abcl-asdf |
---|
1618 | @section abcl-asdf |
---|
1619 | |
---|
1620 | This contrib enables an additional syntax for ASDF system definition |
---|
1621 | which dynamically loads JVM artifacts such as @file{jar} archives |
---|
1622 | via encapsulation of the Maven build tool. The Maven Aether component |
---|
1623 | can also be directly manipulated by the function associated with the |
---|
1624 | @code{ABCL-ASDF:RESOLVE-DEPENDENCIES} symbol. |
---|
1625 | |
---|
1626 | @c %ABCL specific contributions to ASDF system definition mainly |
---|
1627 | @c %concerned with finding JVM artifacts such as jar archives to be |
---|
1628 | @c %dynamically loaded. |
---|
1629 | |
---|
1630 | When loaded, abcl-asdf adds the following objects to ASDF: |
---|
1631 | @code{JAR-FILE}, @code{JAR-DIRECTORY}, @code{CLASS-FILE-DIRECTORY} and |
---|
1632 | @code{MVN}, exporting them (and others) as public symbols from the |
---|
1633 | @code{ASDF} package. |
---|
1634 | |
---|
1635 | @menu |
---|
1636 | * Referencing Maven Artifacts via ASDF:: |
---|
1637 | * The abcl-asdf API:: |
---|
1638 | * Directly Instructing Maven to Download JVM Artifacts:: |
---|
1639 | @end menu |
---|
1640 | |
---|
1641 | @node Referencing Maven Artifacts via ASDF |
---|
1642 | @subsection Referencing Maven Artifacts via ASDF |
---|
1643 | |
---|
1644 | Maven artifacts may be referenced within ASDF system definitions. The |
---|
1645 | following example references the @code{log4j-1.4.9.jar} JVM artifact |
---|
1646 | which provides a widely-used abstraction for handling logging systems: |
---|
1647 | |
---|
1648 | @lisp |
---|
1649 | (in-package :asdf) |
---|
1650 | |
---|
1651 | (defsystem :log4j |
---|
1652 | :components ((:mvn "log4j/log4j" :version "1.4.9"))) |
---|
1653 | @end lisp |
---|
1654 | |
---|
1655 | @node The abcl-asdf API |
---|
1656 | @subsection The abcl-asdf API |
---|
1657 | |
---|
1658 | We define an API for abcl-asdf as consisting of the following |
---|
1659 | ASDF classes: |
---|
1660 | |
---|
1661 | @code{JAR-DIRECTORY}, @code{JAR-FILE}, and @code{CLASS-FILE-DIRECTORY} |
---|
1662 | for JVM artifacts that have a currently valid pathname representation. |
---|
1663 | |
---|
1664 | Both the @code{MVN} and @code{IRI} classes descend from |
---|
1665 | @code{ASDF-COMPONENT}, but do not directly have a filesystem location. |
---|
1666 | |
---|
1667 | For use outside of ASDF system definitions, we currently define one |
---|
1668 | method, @code{ABCL-ASDF:RESOLVE-DEPENDENCIES} which locates, |
---|
1669 | downloads, caches, and then loads into the currently executing JVM |
---|
1670 | process all recursive dependencies annotated in the Maven @file{pom.xml} |
---|
1671 | graph. |
---|
1672 | |
---|
1673 | @node Directly Instructing Maven to Download JVM Artifacts |
---|
1674 | @subsection Directly Instructing Maven to Download JVM Artifacts |
---|
1675 | |
---|
1676 | Bypassing ASDF, one can directly issue requests for the Maven |
---|
1677 | artifacts to be downloaded: |
---|
1678 | |
---|
1679 | @lisp |
---|
1680 | CL-USER> (abcl-asdf:resolve-dependencies "com.google.gwt" "gwt-user") |
---|
1681 | @print{} WARNING: Using LATEST for unspecified version. |
---|
1682 | @print{} "/Users/evenson/.m2/repository/com/google/gwt/gwt-user/2.4.0-rc1 |
---|
1683 | @print{} /gwt-user-2.4.0-rc1.jar:/Users/evenson/.m2/repository/javax/vali |
---|
1684 | @print{} dation/validation-api/1.0.0.GA/validation-api-1.0.0.GA.jar:/User |
---|
1685 | @print{} s/evenson/.m2/repository/javax/validation/validation-api/1.0.0.G |
---|
1686 | @print{} A/validation-api-1.0.0.GA-sources.jar" |
---|
1687 | @end lisp |
---|
1688 | |
---|
1689 | To actually load the dependency, use the @code{JAVA:ADD-TO-CLASSPATH} |
---|
1690 | generic function: |
---|
1691 | |
---|
1692 | @lisp |
---|
1693 | CL-USER> (java:add-to-classpath |
---|
1694 | (abcl-asdf:resolve-dependencies "com.google.gwt" "gwt-user")) |
---|
1695 | @end lisp |
---|
1696 | |
---|
1697 | Notice that all recursive dependencies have been located and installed |
---|
1698 | locally from the network as well. |
---|
1699 | |
---|
1700 | @node asdf-jar |
---|
1701 | @section asdf-jar |
---|
1702 | |
---|
1703 | The asdf-jar contrib provides a system for packaging ASDF systems into |
---|
1704 | jar archives for ABCL. Given a running ABCL image with loadable ASDF |
---|
1705 | systems the code in this package will recursively package all the |
---|
1706 | required source and fasls in a jar archive. |
---|
1707 | |
---|
1708 | The documentation for this contrib can be found at |
---|
1709 | @url{http://abcl.org/svn/trunk/abcl/contrib/asdf-jar/README.markdown}. |
---|
1710 | |
---|
1711 | |
---|
1712 | @node JSS |
---|
1713 | @section JSS |
---|
1714 | |
---|
1715 | To one used to the more universal syntax of Lisp pairs upon which the |
---|
1716 | definition of read and compile time macros is quite |
---|
1717 | natural,@footnote{See Graham's ``On Lisp'' |
---|
1718 | @url{http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf}.} the Java |
---|
1719 | syntax available to the Java programmer may be said to suck. To |
---|
1720 | alleviate this situation, the JSS contrib introduces the |
---|
1721 | @code{SHARPSIGN-DOUBLE-QUOTE} (@code{#"}) reader macro, which allows the |
---|
1722 | specification of the name of invoking function as the first element of |
---|
1723 | the relevant s-expr which tends to be more congruent to how Lisp |
---|
1724 | programmers seem to be wired to think. |
---|
1725 | |
---|
1726 | While quite useful, we don't expect that the JSS contrib will be the |
---|
1727 | last experiment in wrangling Java from Common Lisp. |
---|
1728 | |
---|
1729 | @menu |
---|
1730 | * JSS usage:: |
---|
1731 | @end menu |
---|
1732 | |
---|
1733 | @node JSS usage |
---|
1734 | @subsection JSS usage |
---|
1735 | |
---|
1736 | Example: |
---|
1737 | |
---|
1738 | @lisp |
---|
1739 | CL-USER> (require 'abcl-contrib) |
---|
1740 | @result{} ("ABCL-CONTRIB") |
---|
1741 | CL-USER> (require 'jss) |
---|
1742 | @result{} ("JSS") |
---|
1743 | CL-USER) (#"getProperties" 'java.lang.System) |
---|
1744 | @result{} #<java.util.Properties @{java.runtime.name=Java.... @{2FA21ACF@}> |
---|
1745 | CL-USER) (#"propertyNames" (#"getProperties" 'java.lang.System)) |
---|
1746 | @result{} #<java.util.Hashtable$Enumerator java.util.Has.... @{36B4361A@}> |
---|
1747 | @end lisp |
---|
1748 | |
---|
1749 | Some more information on jss can be found in its documentation at |
---|
1750 | @url{http://abcl.org/svn/trunk/abcl/contrib/jss/README.markdown} |
---|
1751 | |
---|
1752 | @node jfli |
---|
1753 | @section jfli |
---|
1754 | |
---|
1755 | This contrib contains a pure-Java version of JFLI. |
---|
1756 | |
---|
1757 | @node asdf-install |
---|
1758 | @section asdf-install |
---|
1759 | |
---|
1760 | The asdf-install contrib provides an implementation of ASDF-INSTALL. |
---|
1761 | This method of installing Lisp libraries is superseded by Quicklisp, |
---|
1762 | which can be installed via @code{(load |
---|
1763 | "http://beta.quicklisp.org/quicklisp.lisp")}. |
---|
1764 | |
---|
1765 | |
---|
1766 | @node History |
---|
1767 | @chapter History |
---|
1768 | |
---|
1769 | ABCL was originally the extension language for the J editor, which was |
---|
1770 | started in 1998 by Peter Graves. Sometime in 2003, a whole lot of code |
---|
1771 | that had previously not been released publically was suddenly committed |
---|
1772 | that enabled ABCL to be plausibly termed an emergent ANSI Common Lisp |
---|
1773 | implementation candidate. |
---|
1774 | |
---|
1775 | From 2006 to 2008, Peter manned the development lists, incorporating |
---|
1776 | patches as made sense. After a suitable search, Peter nominated Erik |
---|
1777 | H@"ulsmann to take over the project. |
---|
1778 | |
---|
1779 | In 2008, the implementation was transferred to the current maintainers, |
---|
1780 | who have strived to improve its usability as a contemporary Common Lisp |
---|
1781 | implementation. |
---|
1782 | |
---|
1783 | On October 22, 2011, with the publication of this Manual explicitly |
---|
1784 | stating the conformance of Armed Bear Common Lisp to ANSI, we |
---|
1785 | released abcl-1.0.0. We released abcl-1.0.1 as a maintainence release |
---|
1786 | on January 10, 2012. |
---|
1787 | |
---|
1788 | In December 2012, we revised the implementation by adding (A)MOP with |
---|
1789 | the release of abcl-1.1.0. |
---|
1790 | |
---|
1791 | @node Concept Index |
---|
1792 | @appendix Concept Index |
---|
1793 | |
---|
1794 | @printindex cp |
---|
1795 | |
---|
1796 | @node Function Index |
---|
1797 | @appendix Function Index |
---|
1798 | |
---|
1799 | @printindex fn |
---|
1800 | |
---|
1801 | @node Variable Index |
---|
1802 | @appendix Variable Index |
---|
1803 | |
---|
1804 | @printindex vr |
---|
1805 | |
---|
1806 | @node Type Index |
---|
1807 | @appendix Type Index |
---|
1808 | |
---|
1809 | @printindex tp |
---|
1810 | |
---|
1811 | @node Colophon |
---|
1812 | @unnumbered Colophon |
---|
1813 | |
---|
1814 | This manual is maintained in Texinfo, and automatically translated into |
---|
1815 | other forms (e.g. HTML or pdf). If you're @emph{reading} this manual in |
---|
1816 | one of these non-Texinfo translated forms, that's fine, but if you want |
---|
1817 | to @emph{modify} this manual, you are strongly advised to seek out a |
---|
1818 | Texinfo version and modify that instead of modifying a translated |
---|
1819 | version. Even better might be to seek out @emph{the} Texinfo version |
---|
1820 | (maintained at the time of this writing as part of the ABCL project at |
---|
1821 | @uref{http://abcl.org/}) and submit a patch. |
---|
1822 | |
---|
1823 | @bye |
---|