Well, if you want to carry the analogy further, to know Java is to know the basics of how the JVM looks at life. The JVM has concepts of class, inheritance, met

Well, if you want to carry the analogy further, to know Java is to know the basics of how the JVM looks at life. The JVM has concepts of class, inheritance, methods, instances, constructors, and garbage collection baked into it, and they have the same semantics as Java. Arguably, the only difference is one of coding: the JVM codes a Java method as a series of stack-based opcodes, and a class as a set of methods with attributes, but the basic operations are the same. JVM bytecode directly encodes all basic operations: "invoke method X on this class", "declare this method as public and static" - even "if an exception occurs between <this instruction> and <that instruction>, jump <here> to handle it". By contrast, there's a level of indirection between Clojure and the underlying JVM. And so, for much the same reasons as it's a good idea to know some C when doing systems programming, you won't really understand what Clojure is doing (especially not the stack-traces!) unless you understand Java. There's also the practical point that, if you're working on the JVM, you'll be wanting to make use of the massive class libraries available for it. They're all written for native Java, so you'll have to be familiar with Java semantics to use them effectively. (Although the Lispy macro goodness means you can then wrap them up inside a concise functional abstraction when you're using them). If you still want to look at the JVM (for fun, or for implementation reasons), I'd say a good knowledge of Java is enough to just jump head-first into the specification: http://java.sun.com/docs/books/jvms/second_edition/html/VMSpecTOC.doc.html http://java.sun.com/docs/books/jvms/second_edition/html/VMSp...