I am working on a project which has both a Clojure client and a Clojure server. I want to run two REPLs, one for the server and one for the client. I can start and connect to the two REPLs just fine. When I evaluate code in the server.clj buffer, I want it to go to the server REPL. When I evaluate code in the client.clj buffer, I want it to go to the client REPL. Unfortunately, this seems to be hit and miss. The "Manging Connections" docs (https://docs.cider.mx/cider/usage/managing_connections.html) talk about sessions and various commands, but don't understand how to associate a specific REPL with a specific code buffer. I have tried to use the "recency" concept discussed in the docs, by switching to the appropriate REPL and evaluating a trivial expression. I assume this means that REPL is now the most recent REPL. Then I switch to the appropriate code buffer and hit C-c M-z. Sometimes, the code is evaluated in the "recent" REPL and sometimes it's evaluated in the other REPL. This is very frustrating to me. It seems like there should be a simple command to define the desired association; I am probably just not understanding how this is supposed to work. Has anyone done this? Any examples?

I'm not familiar with two repls of the same type. The recency thing is usually for when the repls are clj and cljs, and CIDER gets confused. I'm not familiar with what happens when there are two repls of the same type. If you could file an issue ideally with a repro it would be helpful. I think bozhidar has mentioned he's not a fan of the session management code in CIDER at the moment (lovingly called sesman). I suspect that that will be gutted sooner or later

i hava a java file HelloJava.java in src/java/main

package com.dieya.testjava;

public class HelloJava {

   public static String greetMe() {
      return "Hello, this is Java calling!";
   }

}

(:import 
   (com.dieya.testjava HelloJava)
   )

error in process sentinel: nrepl-server-sentinel: Could not start nREPL server: OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
Exception in thread "main" Syntax error compiling at (app/core.clj:1:1).
	at clojure.lang.Compiler.load(Compiler.java:7652)
	at clojure.lang.RT.loadResourceScript(RT.java:381)
	at clojure.lang.RT.loadResourceScript(RT.java:372)
	at clojure.lang.RT.load(RT.java:459)
	at clojure.lang.RT.load(RT.java:424)
	at clojure.core$load$fn__6856.invoke(core.clj:6115)
	at clojure.core$load.invokeStatic(core.clj:6114)
	at clojure.core$load.doInvoke(core.clj:6098)
	at clojure.lang.RestFn.invoke(RestFn.java:408)
	at clojure.core$load_one.invokeStatic(core.clj:5897)
	at clojure.core$load_one.invoke(core.clj:5892)
	at clojure.core$load_lib$fn__6796.invoke(core.clj:5937)
	at clojure.core$load_lib.invokeStatic(core.clj:5936)
	at clojure.core$load_lib.doInvoke(core.clj:5917)
	at clojure.lang.RestFn.applyTo(RestFn.java:142)
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$load_libs.invokeStatic(core.clj:5974)
	at clojure.core$load_libs.doInvoke(core.clj:5958)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.core$apply.invokeStatic(core.clj:669)
	at clojure.core$require.invokeStatic(core.clj:5996)
	at clojure.core$require.doInvoke(core.clj:5996)
	at clojure.lang.RestFn.invoke(RestFn.java:703)
	at user$eval140$loading__6737__auto____141.invoke(user.clj:1)
	at user$eval140.invokeStatic(user.clj:1)
	at user$eval140.invoke(user.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:7181)
	at clojure.lang.Compiler.eval(Compiler.java:7170)
	at clojure.lang.Compiler.load(Compiler.java:7640)
	at clojure.lang.RT.loadResourceScript(RT.java:381)
	at clojure.lang.RT.loadResourceScript(RT.java:368)
	at clojure.lang.RT.maybeLoadResourceScript(RT.java:364)
	at clojure.lang.RT.doInit(RT.java:486)
	at clojure.lang.RT.init(RT.java:467)
	at clojure.main.main(main.java:38)
Caused by: java.lang.ClassNotFoundException: com.dieya.testjava.HelloJava
	at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:433)
	at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:69)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:586)
	at clojure.lang.DynamicClassLoader.loadClass(DynamicClassLoader.java:77)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:466)
	at clojure.lang.RT.classForName(RT.java:2212)
	at clojure.lang.RT.classForNameNonLoading(RT.java:2225)
	at app.core$eval1595$loading__6737__auto____1596.invoke(core.clj:1)
	at app.core$eval1595.invokeStatic(core.clj:1)
	at app.core$eval1595.invoke(core.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:7181)
	at clojure.lang.Compiler.eval(Compiler.java:7170)
	at clojure.lang.Compiler.load(Compiler.java:7640)
	... 34 more

but in lein repl, it works ok

Is Cognitect actually not sponsoring CIDER or do I just not know how to list the sponsors properly? I'm asking because Calva lists Cognitect's sponsorship quite prominently on https://calva.io/ which makes it feel very official. :)

Cognitect is sponsoring at least Bozhidar, maybe others doing stuff for CIDER, see https://github.com/orgs/cognitect/sponsoring

that's not a complete list, there are also a few under nubank org and on Patreon

I'll feature CIDER in a future sponsorship spotlight on the Deref, feel free to tell me what the best list of people/projects is there

@alexmiller As always you're the best! :) I only noticed this because I jokingly posted in my shop whether anyone had considered moving away from Emacs now that Calva's out and VS Code is eating the world and someone immediately pointed out that Calva's sponsored by Cognitect as a serious plus and I went to go prove that CIDER was sponsored as well and came up empty. ¯\(ツ)/¯

we also buy a lot of IntelliJ Cursive licenses :)

Makes sense but I wouldn't even jokingly imply that someone would consider moving from Emacs to IntelliJ… xD

I did :)

There’s a wealth of open source and proprietary clojure tooling. I am particularly happy when paid products can sustain people. Glad Colin has built such a great product

(If it's not clear I've got no beef with any set of tooling so long as it supports RDD. I'm being lighthearted here. :) )

seriously though, I do a lot of Java interop and impl and IntelliJ is so good that it's worth it for that

Calva is destilled CIDER. Just sayin' 😎

The first Clojure shop I ever worked had some decently serious Java components and we literally kept Eclipse around full time just for the job. I'm lucky (?) enough to write very little Java these days so on the very rare occasion that I jump into that space I still feel mostly happy from Emacs. I think if I did really serious work there I wouldn't have the option to stay away from an IDE. ¯\(ツ)/¯

many years ago, Cognitect funded Counterclockwise too :)

personally, I enjoyed Clojure on Netbeans the most, don't even remember what that was called now

These are deep cuts, Alex. :)

Enclojure!

Emacs as a dev environment and a production ready lisp we’re what got me into clojure. Now I’m on the simplest inf-clojure setup. Just a few handy keybindings to call repl-provided tooling like doc and source

@dpsutton Did you ever give monroe a go?

i have not. i'l look into it

ah, it's nrepl. i'm staying away from nrepl this year. maybe i'll be back but digging it so far

I heard about years ago at this point from someone who said that CIDER had obfuscated one too many issues for them.

Nice.

What repl are you running in the inferior buffer?

socket repls err day. Absolutely lovely to connect locally to the repo or to a production jar and the tooling is identical

download a released jar, check out the code from that commit, socket repl java -jar the.jar with a socket repl command line addition

:grinning_face_with_star_eyes: Dev teaching you skills that directly translate to prod :grinning_face_with_star_eyes:

i think it is more built in tooling from Clojure is everywhere

and using the rich tooling built into the language and not relying on more means a jar and a repo are effectively the same dev environment

how amazingly awesome that a production jar is queryable

Stunningly amazing. :)