Frequently Asked Questions

What is the equivalent of Java import?

To provide a short name for a class instead of the complete fully-qualified name use either define-alias (or define-private-alias) or the import-class combination. For example, to be able to write ArrayList instead of java.util.ArrayList do either:

(import (class java.util ArrayList))

or

(define-alias ArrayList java.util.ArrayList)

Using import is recommended: It handles errors better, and it allows you to define multiple aliases conveniently:

(import (class java.util Map HashMap))

Both forms allow renaming. For example if you want to refer to java.lang.StringBuilder as StrBuf do:

(import (class java.lang (StringBuilder StrBuf)))

or:

(define-alias StrBuf java.lang.StringBuilder)

The name(s) defined by import are by default private. A name defined using define-alias is by default exported; to avoid that use define-private-alias instead.

You can also use define-namespace to introduce an abbreviation or renaming of a class name, but as a matter of style define-alias is preferred.

There is no direct equivalent to Java’s import PackageOrTypeName.* (type-import-on-demand) declaration, but you can alias a package:

(define-alias jutil java.util)
(define mylist :: jutil:List (jutil:ArrayList))

To import a static member, giving it a shortened name (like Java’s static-import-on-demand declaration), you can use define-alias. For example:

(define-alias console java.lang.System:console)

For static fields only (not methods or member classes) you can use an import form, either:

(import (only (java lang System) out))

or:

(import (only java.lang.System out))

This works because Kawa can treat any class as a “library”; in which case it considers all public static fields as exported bindings.

How do I refer to a Java member (nested) class?

Consider the Java SE member class javax.swing.text.AbstractDocument.Content. Using the Java syntax doesn’t work in Kawa. Inside you should use Kawa’s colon operator:

javax.swing.text.AbstractDocument:Content

Alternatively, you can use the internal JVM class name:

javax.swing.text.AbstractDocument$Content

Why does Kawa’s REPL use display rather than write?

The read-eval-print-loop of most Scheme implementations prints the evaluation result using write, while Kawa uses display by default.

First note that it is easy to override the default with the --output-format command-line option:

$kawa --output-format readable-scheme
#|kawa:1|# "abc"
"abc"

The reason display is the default is because of a vision of the REPL console as more than just printing out Scheme objects in textual form for use by a programmer. Some examples:

This "repl-as-pad" model doesn’t work as well if the repl uses write rather than display.