There are certainly binary incompatibility issues between the different versions/branches -- that'll settle out as the core matures, and IIUC, especially once c-in-c becomes a reality.
However, only providing libraries as source (non-AOT-compiled) jars whenever possible only shifts the problem around. Interop requirements are often known of ahead of time (ha!), but many "classloader issues" are totally in the hands of whomever is deploying the end application, their java security policy, etc. In those contexts, having only clojure source libraries available in maven repos is an active hurdle to usage perhaps as irritating as having to unwind "unnecessary" AOT compilation. Of course, people with a strict AOT-compilation requirement can do the AOT-compilation on their own, but I for one do not want to see Gentoo-esque norms emerge in the Clojure community. A more general solution would be to encourage library authors to produce and deploy both source *and* binary, AOT-compiled artifacts, and leave the choice to the library's users. I set this up on Saturday for clutch (a clojure couchdb library and view server) in the process of mavenizing the project: http://github.com/cemerick/clutch/commit/aef461a6fd3c4797aef3b110677197f7351bb831 Then, to depend upon only the source jar in a downstream project, one would simply add a 'classifier' element to the dependency element: <dependency> <groupId>com.ashafa</groupId> <artifactId>clutch</artifactId> <version>1.0-SNAPSHOT</version> <classifier>sources</classifier> </dependency> I think offering both types of artifacts is a much more user-friendly approach, is *very* easy to do (assuming maven usage), and resolves all of the issues in play here (modulo the clojure.lang binary signature incompatibilities that exist, but those should resolve themselves in due course). Cheers, - Chas On Dec 13, 5:44 pm, dysinger <t...@dysinger.net> wrote: > So in my experiments with using clojure / contrib w/ the "new" branch, > I've noticed a pattern of binary incompatibility. Jars pushed to > clojars, maven repos and other places that are are unnecessarily > AOTed, don't work with clojure "new". I noticed the same thing going > from clojure 1.0 to clojure 1.1.0-SNAP. > > It doesn't really seem to matter if you include the src "clj" files > along with the class files in your jar. As soon as clojure hits a > classfile with an older AOTed namespace, it blows up. This isn't a > criticism of clojure. Clojure needs it's freedom to innovate. > > ...but clojure, by default, JIT compile clj files. I would just like > to start a conversation about using AOT sparingly if you publish your > clojure project as a library. Ask yourself "why am I AOTing this > namespace? Do I think JIT compiled dynamic clojure is dumb? Is this a > gen-class I need outside clojure in some fancy XML config file? Is > there some classloader issue that makes it necessary to compile AOT ?" > If the answer is NO, then please don't AOT the code. > > I went through the pain of 3 days of on/off twiddling with libraries > so our project could use clojure "new". The hair-pulling details > where in all the code that was AOT when there was no reason to do > this. 99% of time there were no gen-class or anything else to require > it. People just like compiling stuff [ I get the feeling they think it > has some sort of ricer benefit to AOT compile ]. Most clj files work > great with all versions of clojure if you just jar the clj files and > leave class generation for runtime. > > Don't get me wrong, there are places where a single namespace or two > are necessarily AOTed for interop or for classloader issues. But just > carte blanche AOT makes it harder on other people using your library - > to the point of trying to remove your library from their dependencies > (trust me - been there). > > Code that _could_ run perfectly on clojure 1.0, 1.1.0-SNAP and "new" > are restricted to one version when AOTed and 99% for no reason. > > Maybe Rich can comment on where I am missing it. But I think this is > my stance. > > -Tim -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
