Some questions about JVM debugger expression evaluation

Hi all,

I'm working on debugger expression evaluation for Clojure code. I have it almost working, but I still have a few questions:

  1. When an expression is used for a breakpoint condition, it must return a primitive boolean value. Clojure always returns objects from its functions, so primitives are always returned boxed. I've hacked this in my Evaluator right now to always unbox the return value if it's a Boolean, but it would be nice to be able to tell if this was expected. Is there any way to tell that the expression is expected to return a boolean? Alternatively, is there any way to tell that the expression is a breakpoint condition?
  2. For Clojure stack frames, I'd like to customise some aspects of the presentation. I'd like to customise the stack frame presentation in the Frames tab, and I'd like to customise the display of the variable names (not the values) in the Variables tab since Clojure munges variable names. Is this possible?

Actually, I have another question about the debugger. CLJX is a Clojure templating system that allows code to be shared between Clojure (JVM backend) and ClojureScript (which compiles to JavaScript). How should I handle breakpoints set in CLJX files? I'm guessing I really need two breakpoints to be set - should I do this with a custom breakpoint type which somehow generates JVM and JS breakpoints, or can the user currently set two types of breakpoints on the same line in the same file?


First of all, do you develop your plugin on top of java debugger or general xdebugger API?


Ah, I'm sorry, I should have specified - this is using the JVM debugger.


1. It makes sense to allow Boolean in general, I filed
Until it is fixed you can try using PositionManagerEx.evaluateCondition in debugger-impl (though not in a public API).
2. Frame presentation modification not yet possible, I filed
As for variables:
- you can modify fields presentation: create your own ClassRenderer, register it and override createFieldDescriptor, this is the only way for now
- no way for locals


Ok, thanks Egor.

Do you have a recommendation for the CLJX question? In that case I would need execution to stop in Clojure code (JVM debugger) and ClojureScript code (either JetBrains' JavaScript debugger or one I write specifically for ClojureScript - in either case, the XDebugger API). Should I create my own breakpoint type for this or somehow allow the user to set two breakpoints? I assumed this was similar to JSP pages, but for JSP I guess each line in the file only allows one type of breakpoint?

In general, I'm assuming that for e.g. an application with a Java server and a JavaScript front end, in order to be able to debug both at the same time the user would have two separate debug sessions in tabs in the debug toolwindow, i.e. the debuggers are totally separate and run concurrently. Is this right?


You don't need to create own breakpoint type. You should use JVM breakpoint type.

1) Register own implementation of JavaDebugAware ( Override isBreakpointAware — return true.
2) Register own implementation of PositionManager (, if you want to customise stack frame — implement PositionManagerEx)

Result — you can debug CLJX for JVM.

3) Register own implementation of JavaScriptDebugAware. Please note — class rewriten in IDEA 14.1 (140+ branch). Example — JavaToJavaScriptDebugAware (closed source, 140 branch).
Override getBreakpointTypeClass — return XBreakpointType.EXTENSION_POINT_NAME.findExtension(JavaLineBreakpointType.class).
IDEA 14.1: Override getFileType — return reason == FileTypeRequestReason.EVALUATION_INFO ? _your filetype_ : null
4) Optional, but it seems you should do it in any ase — register own implementation of com.jetbrains.javascript.debugger.FileUrlMapper (it is closed source, JavaScriptDebugger plugin). Example — GwtFileUrlMapper (closed source).

Result — you can debug CLJX for JS. Please note — Clojure complier must produce sourcemap (otherwise debug is impossible). It is the reason why in case of JS you need to implement FileUrlMapper.

>> the debuggers are totally separate and run concurrently. Is this right?
Yes, you are right.

"closed source" == located in ultimate repository. Use decompiler to see class source.


Thanks Vladimir, that's very interesting. I hadn't seen PositionManagerEx, it looks like I could actually use that to solve my previous two problems of the boolean return code and the stack frame customisation, too.

I'll try to implement all this and return with more questions if I can't get it to work. Thanks again to both of you for the very useful posts.


It's been a while since I wrote this, and I see the JVM debugger has seen quite a lot of work in recent times. Has there been an update on these items?

  • Is it possible to customise stack frame presentation yet? hasn't seen any updates, but I thought I'd check.
  • Is it possible to customise the names used for local variables, both in the debugger view and also for values painted into the editor?

I have a further question - the JVM debugger now supports expression-based debugging, i.e. breakpoints which are not strictly line-based. How does this work? What is required for me to implement this for Clojure?


Hi, not much news, sorry:

you can use PositionManagerEx.createStackFrame to replace the JavaStackFrame with your inheritor, override getVisibleVariables to replace variables.

This is not really convenient, but nothing was improved here, sorry.

As for the breakpoints, use XLineBreakpointType.computeVariants to provide available line options. createProperties in the selected variant will be used to create propper breakpoint.


Thanks Egor, I'll investigate all of that and try it out.


Please sign in to leave a comment.