This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # babashka (22)
- # beginners (8)
- # calva (7)
- # clj-kondo (65)
- # cljdoc (9)
- # cljsrn (1)
- # clojure (53)
- # clojure-australia (4)
- # clojure-europe (49)
- # clojure-gamedev (2)
- # clojure-italy (13)
- # clojure-nl (1)
- # clojure-spec (19)
- # clojure-uk (4)
- # clojurescript (48)
- # clojureverse-ops (1)
- # core-async (3)
- # css (2)
- # cursive (15)
- # datomic (6)
- # degree9 (2)
- # depstar (4)
- # emacs (2)
- # find-my-lib (1)
- # fulcro (16)
- # graalvm (11)
- # gratitude (1)
- # honeysql (9)
- # introduce-yourself (2)
- # jobs (1)
- # joker (2)
- # livestream (2)
- # malli (16)
- # nbb (4)
- # news-and-articles (2)
- # off-topic (1)
- # pathom (7)
- # polylith (10)
- # practicalli (1)
- # re-frame (7)
- # reitit (1)
- # releases (3)
- # remote-jobs (1)
- # rewrite-clj (19)
- # shadow-cljs (10)
- # tools-build (1)
- # tools-deps (9)
- # uncomplicate (1)
- # vim (3)
- # xtdb (44)
I need to extend some Java classes. I’ve been pretty happy with Clojure’s interop so far, but this seems to be an area where interop is a lot more complicated, e.g. a sudden proliferation of namespaces with
(:gen-class ...) containing lots of interop-specific key-value pairs. Does it even make sense to attempt interop in this case, or am I better off just writing Java code and importing that into Clojure somehow? What are your experiences?
Sometimes you can get rather far with just
proxy. But if that's not the case, you might want to take a look at these libraries that let you generate JVM bytecode using Clojure, seemingly with no hassle:
Clojure itself has something similar in the
clojure.asm namespace, but it's more cumbersome to use:
And if you decide to go with writing plain Java and using it within a Clojure project, I can give you a few more links.
Thanks. JiSE looks a lot more manageable, while insn reminds me of :gen-class. Do you have any experience using either?
Nope. :) I just hoard links. I used Virgil in a similar situation - but I didn't know about the above back then. Nowadays I wouldn't recommend it.
@U3L6TFEJF I’m using tools deps, not Leiningen or Boot, so I guess Virgil isn’t as plug and play.
Hmmmm… JiSE says it does support inheritance, but I can’t figure out how to extend a class. None of the example or the tests seem to do that. I really wish there was a Java-in-deps.edn solution that was good to go.
There are such solutions: • https://github.com/IGJoshua/americano • https://github.com/EwenG/badigeon • https://github.com/just-sultanov/ninja.platform/blob/master/docs/ninja.tools/javac.adoc
I also found this for the newly-released tools.build: https://www.clojure.org/guides/tools_build#_mixed_java_clojure_build
Still not sure which one to pick. I guess americano seems to be the most friendly option.
Just wanted to report back that Americano is incredibly simple to set up. It does require running
clj -X:compile-java to recompile (there is no automation of that step AFAIK). In the meantime, I’ve discovered on the mailing list of the Java framework whose class I was extending that I didn’t actually need to extend anything, I could simply mutate an instance of a generic class to get nearly the same result, so I reverted my Java code commit and went with that solution instead. Still, I’m really happy that I tried out Americano and I will definitely use that next time I need to write some Java-in-Clojure.
> there is no automation of that step AFAIK You should be able to do that by making Americano a part of your app and just calling the compilation code - that's exactly how I used to use Virgil. But not sure if it's a good thing to do.
Hi all, I’m working out the various components to use in a backend web stack today and was wondering what the idiomatic database libraries are right now (excluding Datomic - considering it but would like to see the other options). I’m planning to use Pedestal at this stage but can’t seem to find a database library that works asynchronously. I’m coming from a mostly Rust and Python background the last few years so maybe I’m missing something.
I would start with selecting a DB itself first, and only then a library.
If you're fine with PostgreSQL or any other JDBC-compatible DB, take a look at https://github.com/seancorfield/next-jdbc
There's no async support out of the box, as far as I can tell, but you can easily wrap what you need in threads. If you use
core.async, there's a handy
Thanks for the reply!
Postgres is indeed what I’m leaning towards as I have experience with it already. Will using
core.async/thread spin up a new thread with all the overhead that entails or will it utilise its own thread pool? I’ve had a quick glance at the source and can see it uses
Executor/newCachedThreadPool but I’m not experienced enough with core.async to follow whether that starts one or re-uses one.
It’s own, already-running one?
Thread pools don't run, they manage threads. It already exists. It will launch new threads as needed, and it will cache them. Threads that haven't been reused for long will be pruned from the cache to free resources.
You also want to use this to avoid opening new connections every time: https://github.com/tomekw/hikari-cp
Ok, got it. Thanks for the help!
You seem like you’ve already settled on going async. Why would that be? IMO (not having programmed much async) the sync model is much easier on the brain and the JVM works rather nicely with threads. Put in another way. Unless you know that your app will have a lot of traffic with potentially long running requests, I’d go with a synchronous approach.
core.async. You can have the first without the second. Using threads could also be considered async programming. But up to OP to decide what it means in their context.
I mean async in the sense of non-blocking io with work distributed among threads (reactor). I also prefer threads for almost every task but this is one case where the memory saving from going async is worth the burden. Requests will all have several operations that need to be performed before responding, this affects latency of course but for the application it’s fine.
For context I’m coming at this from a Rust and Python background mostly. I have also done epoll work in C many years ago.
Non-blocking database drivers on the jvm have not achieved wide popularity in the clojure ecosystem. If that's something you believe you need I'd probably look at r2dbc or vert.x. For your awareness there is also a jdk project that has been underway for a while that seeks to virtualize threads largely as-is rather than requiring you to use a different api when you want the benefits of non-blocking code. You can read more about it here: http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html
I’m eagerly awaiting the landing of Project Loom!
What's a good way to make the following refactoring? :
|-maindir |-|-subdir |-|-|-lib.cljs (ns maindir.subdir.lib) |-|-|-anotherlib.cljs |-|-|-yetanother.cljs |-|-|-alsothis.cljs *abra kadabra* \ / \/ |-maindir |-|-lib.cljs (ns maindir.lib) |-|-anotherlib.cljs |-|-yetanother.cljs |-|-alsothis.cljs
For the sedding and diffing I will use emacs.
mv is reliable, "one by one" is an acceptable answer 🙂
Actually the only replacement needed is removing ".subdir." from everywhere, not that bad.
I'm probably too late but since you're using emacs, dired should be a better choice than vanilla mv
this is one of the few cases in clojure where you can do a compiler guided refactor - for every ns form that does not match the path to the file, the compiler will complain, you can repeatedly fix the declarations and reload your namespaces until you get no such complaints
Thats what I eneded up doing, I don't know how to use dired yet beyond the most basic survival, but ivy occur edit mode was amazing help in locating and editing names across multiple files at once
what I said above was incomplete, of course. you get two compiler errors, one when the ns decl doesn't match the path to the file, the other when the required ns no longer exists due to the refactor
Late to the party, but I've previously done this in stages.
git mv (not just mv), and commit to do the most disruptive part of the refactor (file renaming)
2. global sed-replace to fix ns declarations and references everywhere (src, test, comments, docs, scripts etc.)
sed -i -e <pattern1> -e <pattern2> ...
a. After that, it helps to grep -R <token> to identify various unexpected patterns I might have to further sed/replace
git add -p to review+stage each rename piece by piece, and of course git commit
4. run tests as well as build jar and run app and exercise it to see if it all appears to work
git squash to make the whole refactor a single atomic commit
Hi, https://github.com/yogthos/migratus is still the most common way to manage DB migrations ? (like Rails migrations or similar)? thanks
https://github.com/weavejester/ragtime is the other common one. If I was starting over, I'd probably use Migratus instead of a custom in-house solution (ours dates back a decade and has slowly evolved).
We use semi-structured data-stores, and manage document versions in application code with Spec. So we write our code so it works will all prior versions of the document spec, and knows how to update it to the latest. Which may or may not be more complicated than a migration strategy :man-shrugging: , but at least it lets us have zero downtime, since we never need to do a big bang migration on the data-store
In our case it does mean that data is forever though, and so overtime, you continue to need to deal with the historical versions of the data you ever had.
We generally try to make sure that DB migrations can always be applied while the system is live so when we are planning a DB change, we'll make sure the code will work with either today's DB or tomorrow's DB -- which means we might need to roll out some changes to code first -- then roll out the DB migration then maybe roll out code changes to remove the multi-version handling. But, like @U0K064KQV’s scenario, that's all somewhat meta and tangential to the actual DB migration machinery itself.
I've had a fair amount of success with https://flywaydb.org/ in the past.
great, thx guys, I will take a look in these libraries as well.,
In my previous job (non-Clojure) we used Flyway to migrate our AWS Redshift database. I made a CI/CD pipeline based on Flyway, so we could validate schema changes on our 'test' scratch DB instance (schema only) and 'staging' DB instance (schema + test data) before rolling out to the 'production' instance. Flyway was pretty solid and straightforward with all this chicanery going on.
I'm curious, what does it do exactly that's not just running a SQL script? A quick glance and it seems to offer very little over migratus or ragtime but appears to have some commercial aspects to it?
There's a chart comparing free and commercial versions of Flyway on the download page : https://flywaydb.org/download The free version was sufficient for our needs at my old job.
One of the advantages it has over, say ragtime, is that it will lock to ensure that the migrations are only being run by one process at a time. So if you, for example, ran the migrations in a k8s pod at application startup and you ran many replicas, only one of those processes would actually run the migrations. With ragtime that's your problem. I've never used migratus, so I can't comment on that.