As long as you're not AOT-compiling Clojure (i.e. producing class files, which is generally entirely unnecessary in Clojure except perhaps as the last step just prior to application delivery / deployment), you'll generally be very happy.

The 1.2 -> 1.3 transition has had a couple of bumps, but nothing compared to the pain I recall from my time across Scala versions years ago. FWIW, I have code I wrote years ago against pre-1.0 Clojure that still sits in jars in my Maven repository that is loaded and run in 1.4 alphas today. Backwards compatibility is mostly quite good.

In the JIT world, going .java->.class is not AOT. You may call it that, but it's essentially just source->source conversion.

What AOT really is, is when you first run a java program with certain flags, and some compilation starts, a special AOT version, which is usually a low optimization level which is saved to disk with some relocation markers.

This helps with startup time in subsequent runs as the compiler can just load its baseline pre-compiled classes straight into memory instead of having to do a bunch of grunt work during startup. Once things get going, the compiler can much more quickly work its way up to the higher optimization levels on the sections of code that need it.

THAT is what AOT means from a jitted language perspective.

Java bytecode is what we mean when we say 'compile'. AOT is 'ahead of time' with regard to clojure, since it compiles to bytecode at run-time normally.

"AOT" in the clojure world means compiling your clojure source down to JVM bytecode, which also means compiled-in calls against a particular state of clojure's internal java api. By shipping clojure source, one avoids any concerns over incidental changes to internal code.

As both a Scala and Clojure user, I believe this is primarily a Scala-specific issue. The one caveat to that is that, if you're using Clojure and AOT-compile your code, you can run into some issues if you are trying to use AOT-compiled code from different versions (or using a different version of Clojure than the one used to AOT-compile the code).

Now, there have been some source-level incompatibilities, especially going from Clojure 1.2 to 1.3, and this seems to have been a bit of a headache within some parts of the Clojure community.

It's not true of Java - the bytecode generated by javac is very robust in the face of new JVM versions. This is one of the reasons that Java has had to move so slowly in terms of language features.

Neither Scala or Clojure's compilers generate byte code that is expected to work with that from another version of the respective compiler or with a different version of the language runtime.

In the case of Clojure this is mitigated by the fact that (since it is a dynamic language) that applications and libraries are generally delivered in source form and "ahead of time" compilation is seen as an optimization rather than a code delivery mechanism.

Pretty sure this isn't even language specific. If you are using a library that drastically modifies how they implement something between versions, then you will run into this. Even in pure Java. Now, the ecosystem in Java is to usually not make large changes. At least not at the public API level.

I think Scala is slowing down in this area, but have not stopped.