A library that I'm publishing on clojars requires some AOT compilation due to :gen-class. I'd ideally like to allow users to have this library as a git dependency too. My question is this: does the Clojure compiler produce bytecode that's dependent on the JVM version it's running on? e.g. if I compile on openjdk11, will I be able to rely on the classfiles generated being able to run on openjdk8?

@suskeyhose More to the point, if you compile code against a specific version of Clojure, people using other versions might not be able to use your library.

That's a good point, but an unfortunate requirement. In this case, the actual generated code is exceedingly simple, just a call to = and a couple of keyword lookups on the state of the generated class, which extends java.lang.Error

Oh and the class implements an interface for a protocol

So I'd imagine it's unlikely to see version conflicts.

Not a good idea

Aot compilation works best at the end of the dependency chain (you might aot your final program)

If you start inserting aot in the middle (aoting chunks of libraries) things can go very wrong

Yeah, I've been over this before. The unfortunate reality is that with the current facilities Clojure provides I cannot extend Throwable in a way that I can catch the resulting class without :gen-class

The hazards you have to navigate are largely related to aot compilation being transitive, and order dependent

So aot compiling code will aot compile everything it depends on

There is exactly one namespace that needs aot compilation, and it only needs to create a named subclass of Throwable.

@suskeyhose stay tuned for some new features in the hopefully imminent future

Thanks alex! I'm looking forward to it!

Which will, if you package it in a jar, result in something like an uberjar

Which depending on can lead to all kinds of dependency conflicts

Sure, except in this case there are no transitive dependencies of this namespace.

Well, clojure.core is a dependency I bet?

So compiling your single namespace will cause a bunch of compiled .class files to appear I suspect.

depstar allows me to elide all of the clojure.core class files

and that has worked fine when depending on it from clojars.

Eliding class files can be done, but it will also break things sometimes

clojure.core is already compiled so will not produce any class files there

Fair enough. I don’t like to encourage AOT for libraries (and I think you get a warning, yes?) but some folks insist…

Yeah, I would love to avoid aot if I could

Because the next time whatever elided clojure code is compiled it may not have the same class name

So your aot compiled code may refer to a class that doesn't exist any more

Yes, it will not produce any clojure.core class files, but I had to elide some clojure.core.specs.alpha class files

Yes, I would love to avoid aot completely, and if you have a way I can extend Throwable and catch the resulting class without aot, I will gladly switch.

ideally, relying on ex-info is better

Unfortunately that's not an option in this case because this is for control-flow constructs and I can't rely on third party code to re-throw the ex-info

For reference, this is for https://github.com/IGJoshua/farolero

@alexmiller If you compile a very simple namespace, even though you don’t get classes from clojure.core, you do get classes from core.specs.alpha in your classes folder.

Yup, I had to elide those

Since @alexmiller is around: what about the OP’s Q which we haven’t answered yet… “if I compile on openjdk11, will I be able to rely on the classfiles generated being able to run on openjdk8?”

should be, they are java 8 bytecode

whether or not you make calls to jdk apis added after java 8 requires more discipline

Cool. I had a feeling I’d seen that as an answer to another question here recently.

Awesome, that helps out a lot.

Yeah, I'm not calling any JDK api, all I'm doing is extending java.lang.Error with a named class that has a protcol implementation that checks if the argument is equal to an item in the state.

there is a lot of fud around aot. it's not conceptually any different than all java libs that "aot compile". there are some issues for sure - we may take on making those issues less of a problem.

Although now that I think about it, I could potentially reduce how much is AOTed by using extend-protocol in the other namespace.

rather than directly extending the interface

“fixing” the transitive compilation stuff would probably be the #1 thing folks seem to want (although there are tooling workarounds) — but I understand that there are complexities behind that.

Making it easy to compile some thing(s) at the point of use, i.e., via a command that runs code, would also probably satisfy what most folks actually need 🙂

Yeah, that or a way to extend classes while generating a named class is all I need

in order to completely remove aot from the equation

all of those things are up for consideration

On mobile, but would it be possible to put your error class as a stand alone maven project and just depend on that from your clojure project?

Then no aot and can use git deps and anything else you like

Hmm. Except for the ns form, I think I could actually entirely remove the dependency on clojure.core

That's actually a good question @dpsutton

I'll consider that. It depends on what gets generated once I pare down what's actually in the aot-ed part.

I think I can get everything that's there down to special forms.

I think two jobs ago we did something like this and just compiled it once and stuck it on the class path.

Checked in and everything if I remember correctly

Alright, well after getting it down to just special forms and an ns clause it's still a few too many class files. I think I might just make a java artifact that I can put out on clojars.

Thanks for the suggestion @dpsutton!

@suskeyhose one thing that i think might be worth investigating is just using https://bytebuddy.net/#/

making your class and loading it into the right classloader

I think that adds more overhead than just making an additional jar with the single class file in it, and it certainly increases the runtime overhead for users of my library.

Clojure has a censored version of asm

Vendored

If you are willing you can do all kinds of stuff with it https://git.sr.ht/~hiredman/reagents/tree/master/item/src/com/manigfeald/reagents/struct.clj

(oh, I forgot that is such a heinous arrow)

I’ve just adopted using component(https://github.com/stuartsierra/component) in my project, and I’d like to know how others think about the experience. I haven’t checked, but there seem to be quite a few alternatives like integrant and mount. It might be because I’m inexperienced, but restructuring a non-component project (which was made of many global singleton defs and defns) into a component project wasn’t easy..

Is anyone aware of a utility lib that has a hybrid let/`letfn` macro? I often want to use letfn but end up just going with a let as I also need let-like bindings in the same scope and don't like the idea of adding yet another level of indentation. I'm looking for something where you can mix let and letfn style bindings in the same binding vector

I hardly use letfn, I just can't remember the syntax. Imo letfn is useful for mutually recursive fns, but in other cases, I would just use let

my code is usually littered with letfn , and I’ve also often wished to mix let with letfn but not often enough to write the macro.

@imre what would be the clojure ideomatic way to distinguish the two types of bindings? For example, I very well might want to bind a variable to a vector. would it be the case that a list of 3 or more components whose 2nd element is a vector is necessarily an attempt to bind a function? and the macro could simply insert the (fn …) around it? or would you want something more exotic?

Is it possible to test macro expansion? I have a branch in my macro that throws an error when given incorrect code. I’d like to write a test to demonstrate that. Is that possible?

yes with macroexpand, macroexpand-1 or clojure.walk/macroexpand-all

I’ve only ever used that at the repl. They don’t return strings, they return the actual code?

correct

macroexpand takes a form and returns a form

Cool, I’ll give that a try

Coming from ClojureScript I was suprised that defrecord behaves differently in both:

(defrecord Service [send-query])

(defn make-send-query []
  (fn [foo] foo))

(let [s (->Service (make-send-query))]
  (.send-query s "foo"))
; ^ Throws in Clojure (no matching method), but works in Cljs

you should not be using interop syntax to invoke

record fields should be accessed like maps

I see thx :thumbsup:

in both clj and cljs

so this would be a proper use for Protocols I guess

((:send-query s) "foo") is I think what you're doing?

you can certainly do the equivalent with protocols too

(protocols are mostly just implemented as maps of types to functions)

yeah that works in both

thanks!

The lower level syntax for accessing these fields is (.-send-query s "foo") which works in both, but it's more preferable to access those via either keywords or protocol fns (in the case of deftype)

That (.send-query s "foo") works in CLJS might be just accidental since the . is quite overloaded in CLJS

does anyone know how I can contact Sam Ritchie ?

@jimka.issy #sicmutils

Through generative testing I found this behavior which I find surprising. In the context of maps and sets, [] and (list) are equivalent:

{[] :vec, (list) :list}  ;; Throw, duplicate keys

(hash-map [] :vec (list) :list)  ;; Super weird => {[] :list}

;; And similarly with sets

In CLJS (at least, planck) {[] :vec, (list) :list} doesn't throw though, it's something only the JVM Clojure seems to do

They have the same hash for some reason and are equal in CLJ.

But Lumo (CLJS) returns {'() :list} , which is inconsistent with Clojure JVM

sequential collections compare equal. equal things have the same hash.

user=> (= [] (list))
true

hash-map docstring explains why different than literal (... "as if by repeated uses of assoc")

in clj -A:cljs -M -m cljs.main -r {[] :vec, (list) :list} returns {[] :list}

$ bb -e '{[] :vec, (list) :list}'
{[] :list}

Right, so this is not specific to empty colls then, it is indeed about hashing. It has never bothered me with = , but after years of Clojuring, I kind of freaked out seeing that behavior with keys :p

it's just a subtle difference in the behavior when the key is already present and a new value is assoced.

Yeah, I try to stick to [] (vectors as opposed to lists/seqs) nowadays for everything which is data but definitely not code in the “final” output; eliminates this kind of “worry”

Unless I specifically want to keep something as a, say, list, so I can keep adding to the front; That’s rare.

@alexmiller I watched your video on Clojure Spec from about 1 year ago. Just wanted to say thank you for all the hard work you have done leading the community. It has kept me interested in using Clojure. Spec is an amazing tool. And you picked the perfect images for your talk. Of the bird.

thank you