Skip to content


Subversion checkout URL

You can clone with
Download ZIP
SWANK and nREPL servers for clojure providing JPDA based debuggers
Common Lisp Emacs Lisp Clojure Scheme Ruby Shell

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.


Refactored swank-clojure, with jpda debugging support.

This is alpha quality.

  • Breaks on uncaught exceptions and breakpoints.
  • Allows stepping from breakpoints
  • Allows evaluation of expressions in the context of a stack frame
  • Inspection of locals in any stack frame


Add [swank-clj "0.1.3"] to your project.clj :dev-dependencies.

Install the slime-clj.el contrib from marmalade.

A compatible slime.el is in slime/slime.el. It is available as a package.el package file you can download and install with M-x package-install-file. Note that you may need to remove this package to use swank-clojure again.

If you would like to browse into the clojure java sources then add the following to your :dev-dependencies, with the appropriate clojure version.

[org.clojure/clojure "1.2.1" :classifier "sources"]

For clojure 1.2.0, you will need the following instead:

[clojure-source "1.2.0"]


To run with jpda:

lein swank-clj

To run without jpda:

lein swank-clj 4005 localhost :server-ns swank-clj.repl


To set a breakpoint, eval swank-clj.el from src/main/elisp, put the cursor on the line where you want a breakpoint, and M-x slime-line-breakpoint.

Note that breakpoints disappear on recompilation at the moment.

To list breakpoints, use M-x slime-list-breakpoints or press b in the slime-selector. In the listing you can use the following keys

  • e enable
  • d disable
  • g refresh list
  • k remove breakpoint
  • v view source location

Open Problems

Recompilation of clojure code creates new classes, with the same location as the code they replace. Recompilation therefore looses breakpoints, which are set on the old code. Setting breakpoints by line number finds all the old code too.


A pure JDI backend, that doesn't require swank in the target VM is certainly a possibility.

A slime-eval-symbol-at-point would be useful (requires determining the frame in the current sldb stacktrace using file and line number).

Add watchpoints with logging of locals to an emacs buffer or file.

Use Cases


Run swank server and JDI debugger in the same process to have a single JVM and keep memory usage down


Run swank and debugger in a seperate JVM process. Attach to any -Xdebug enabled JVM process.

Production server

Run swank server in process and attach slime as required. This requires the debugger to run in process.


Copyright (C) 2010, 2011 Hugo Duncan

Distributed under the Eclipse Public License.

Something went wrong with that request. Please try again.