Clojure Core Team Dev Call, Feb 2026

Okay. Well, should we should should we kick it off? Should we get started? >> Yeah. >> Okay. Welcome everybody to our first closure core dev call. So, this is uh going to be an ongoing thing where we take a moment to talk about things the core team has been up to, what's on our horizon, um just share out and give people a opportunity to ask some questions and uh interact some more with core team. So, we're really happy to be here and do this and we're really happy that you are also here to uh join us for this uh first occasion. So, we're going to be running through a few slides and then we're going to go into the Q&A after that. So, we definitely want to save time for Q&A. go. Uh, if you have a question, if a question pops into your mind as you're listening, go ahead and go to the Q&A button at the bottom and submit your questions via the Q&A feature. If you put it in the chat, it, you know, it's just going to scroll right by. Who knows if anyone's going to see it. So, so go ahead and use the Q&A feature to ask a question and uh, and we will answer those questions as as we uh, go along. Okay. So, I'm gonna send it over to Alex to kick off the call. Alex, >> I'm gonna send it back to you because I don't think you introduced yourself. [laughter] >> Oh, I'm sorry. My name is Kristoff Newman. I'm the closure developer advocate on the core team and uh I've been around for less than a year now. Some of you I have met at the Kunch and some of you I've just seen you in Slack and online, but um yeah, it's a pleasure to be here. All right, I'll take it back. Um, I'm Alex Miller and I run the closure team at Newbank, which is uh a subset and a superset of or a a subset of the closure core dev team. Uh, we do uh still work with Rich regularly, but uh he's uh part of being retired is that he doesn't have to show up for things. So, he's not here today, but uh he is here in spirit. And um for this first uh dev call, we're trying to we're planning to do this kind of roughly quarterly. Um we'll see how that goes. Um but for this one, because we haven't really had a lot of outward communication for the last year or so, I thought I kind of it will be more backward-looking because um we had just to sort of sum up what we've been working on. So I kind of cast my eye back to about a year. Um, so that's kind of roughly the time span scope of this. Most of this is going to be backward-looking, a little bit of forward-looking stuff. Um, and I think that as we go forward, future ones will be probably a little more tilted towards the forward-looking as we have less backward-looking stuff. Uh, so we're going to start with talking about closure, and I'm going to throw this over to Focus and let him talk about uh the first couple uh point releases we did last year. >> Yeah. Hi everyone. Um, my name is Mike Fogus. I'm calling in from uh Virginia in the United States, just south of Washington DC. And uh, so I'm going to try to think back over the the past year and and give give the best little introdu uh, best little overview that I can. So we started uh, with closure 121. Uh, that was this was a dot release uh, fixing up some bugs in our o our release. Uh first was uh you know we we added a big thing in in uh 12.0 which was which was around uh uh uh symbol uh class class methods and and and array uh classes and and so we were cleaning up some of that and and so there was a there was a problem where uh if there was a qualified symbol which could which it could have named a class or a field or something uh in invoke position uh we were choosing the wrong thing which is which is old old closure would choose the method and we were closing choosing the field uh so we we cleaned that up. Uh Alex added a bunch of stuff in for uh using uh uh adaptable objects uh as functional interfaces and there was a little bit of cleanup around that uh where there was where we could have an object that was a function uh that was being wrapped being adapted unnecessarily. So so there's a little bit of conditional code added to that to clean that up. Um so yeah, fixing up uh one one Part of the array class problem was the gen class didn't recognize it. So there was a there's a little function called the class that that uh was changed to uh identify uh array array classes and and do the right thing in in the gen class uh uh uh code. Um uh there was some uh feature uh there there was there was a there was a bug uh fixed in in ad libs uh where um there there were uh procure keys and and I I don't I screened it but I I can't remember exactly what it was but there there was a white list created for privilege uh prefix keys and and so uh uh that that uh is now in the um for tool invocation Uh and uh the last one for uh the release.1 release was uh just adding some some metadata that we missed on some functions. So it's some easy stuff there. >> Cool. >> I'll continue on. 112 was was uh some more uh uh clean up around the um the qualified uh symbols, qualified method symbols. And so uh um the there was a uh an error where if you if you were calling a method uh that didn't an instance method that did not have a uh a target a target object uh you would get an error. It was always an error. It was still an error. It was just the wrong error. And so we we made it the the the error that it used to be. Um there was some uh there was some uh uh little bit of extra uh objects being created in in the locking transaction uh for the retry uh exceptions and so uh that was reduced from a bunch to one uh uh there was some stuff done around lazy seeks and uh >> bogus do you want me to take these last two >> uh yeah I go ahead you know I think straightforward, but you have a lot more context around it. >> Well, I I wanted to mention these in particular because they were um reported to us um privately as potential uh potential CVE type things. Really, the the CVE is that Java serialization is sort of broken by design and that uh you're deserializing arbitrary objects and running arbitrary code uh while doing so. And so in general I'd say that there's a bug in Java which is that deserialization exists but that's not really one that they that they agree with and and are going to fix. So we've had a several issues over the years with uh what are called gadget chains which is this technique to uh basically handcraft uh malicious serialized objects. And if you can do that and if you can convince an an application to des serialize those objects uh then um through some chain of gadgets that causes arbitrary code to get run during deserialization then uh that that's seen as a CVE and there's been a number of these filed on all the different JVM languages over time. We've fixed some in the past. Um so there were two that we fixed in this release. Um, one is that uh lazy seeks uh by their nature um really both of these cases are ones where there is a field that's an iPhone and if you have a field that's an iPhone that's going to get executed during deserialization then or could be caused to be ex executed during deserialization then you've basically created an open door for people to run arbitrary code. So uh both of these are um ca the only two other cases of this. There is one other one that we closed in the past I think. Um and so with lazy seek the way we changed that was to um basically we realized the lazy seek before we serialize it. Um that means that if you have an infinite lazy seek uh it would have worked before but no longer serializes. Uh this is not something that is commonly usually closure developers don't use serialization. They use uh uh writing printing to a stream and they print either Eden or transit or something else. Use one of the various serialization libraries to serialize data and don't use Java serialization. So this is not a commonly used feature. Uh, I did ask on Slack how many people were using Java serialization at one point about a year ago and I got 68 nos if I recall correctly and zero yeses. So [laughter] that's not a commonly used thing but that was the change we did there. And with iterate, iterate is also a thing that holds an arbitrary function. Um, so basically I just made serialization and deserialization fail uh in those cases where they used to succeed. So, those are some small corner cases. I've not had anybody report to me that this was an issue since we did it. Um, but those are out there. Uh, and I'll continue on. Um, closure 1123. This was an issue that we ran into with core async a few years ago. It's the famous uh I think the error you get is something like underscore funk not found or something like that is what you see. And uh uh once we understood the problem, I actually was able to find an older case of it in Jira from like 10 years ago and this goes back to actually the uh I don't know it's even older than that the original code um that so it's been in there for a really long time. But um the problem here is if if you are um in a nested compilation context which is a little difficult to get into but if you are uh compiling and then you run a macro and that macro loads some code and that code is running something at the top level. So if you have a defaf that's doing something like that uses either keyword call sites so basically doing a lookup with a colon keyword as the invoke in and the invocation position or uh with protocol call sites which we've never had reported um but I was able to construct such an example uh once I knew what to what to do um then it would basically uh the compilation state does was not getting properly reset at that point. Um, and so you could get basically this there's a keyword callite optimization that happens and part of it would get emitted in the nested class and part of it would get in emitted in the parent class. And so the part that had the code but not the field would throw this error, the thunkk error. So, uh, that's kind of a kind of a very obscure one. It took quite a while to figure it out, but uh I would definitely recommend moving to something later that fixes this, even though most people don't ever run into it. Uh and then Closure 1124 is kind of an interesting one. Uh and I would really recommend that if you're not using Closure 1124 that you update to it. Um in closure 112, we made some changes to um Lazy Seek to fix a concurrency issue there. Uh that well, not a concurrency issue. So, let me back up. So, when Vthreads were added in in uh Java 21, um Java 21 did not have um support for synchronized uh in vthreads. So, if you were um running code in a Vthread and you synchronized, it will it would pin the virtual thread and not allow it to be um uh what do they call it? uh pulled off of the pulled off of the uh carrier thread. So uh that could cause you to increase the number of actual platform threads that were being used and not get all the benefits of virtual threads. There's only a couple places in closure where uh we run arbitrary user code under synchronized. This is not a problem for all uses of synchronized. If you're using synchronize to like access a field or set a field like that's generally fine. It's when you're access synchronizing and doing some sort of potentially blocking action inside of it that it's a real problem. Um so the two places in closure where we run arbitrary user code under a lock are lazy seek as you're realizing the lazy seek you could be doing arbitrary stuff or in delay. Um so we made some changes uh to fix both of those things in not fix but to change the way it was implemented so that we were not holding a synchronized lock. We switched to using rant lock which is fine in Java 21 uh and does cooperate with virtual threads. Um unfortunately we introduced some issues with visibility in there and that means that you could see um there's a data race basically and it's possible to see incorrect values as you realize a lazy seek. You have to be doing that in a concurrent way which most which is not common. Um but this actually came from a case reported by a Dayic customer. Um the Daytomic team narrowed down the actual code in question. uh as far as they could tell what they were seeing was impossible based on the state of the code uh and they were right if you assume that lazy seek is correctly uh uh synchronizing. So it was pretty easy to at that point to to see the problem in lazy seek and and we uh reworked uh some of the concurrency uh constraints in there to uh basically avoid uh any sort of data race. Um and it actually cleaned up the code as well. So it was good. It was a good It was a good change, but I would I would urge you to use move to Closure 1124. Uh you get all those fixes we just talked about. U there shouldn't be any issues as far as you know regressions or anything like that from closure 11200. So that would be my recommendation of the day. Uh and then uh let's talk a little bit about closure 113. We've done a bunch of work. Um that work is not particularly visible yet. [laughter] And then we also have some um some additional things that we've started working on that I'm not going to talk about yet, but um maybe at the next one of these calls we can talk about that. Um so one of the bigger things is we did a lot of work with um preparing to move to a newer JVM as the baseline. So we've been using um Java 18 as the baseline or Java 8 both are commonly uh named for it. um for several releases now. I think we switched in either Closure 1 N or Closure 110 somewhere around there um to using Java 18 as the baseline. Uh that is getting more and more difficult to maintain as our tooling moves past that point. Um we're still hanging on out there, but I can see the writing on the wall. So, we're we figured we would kind of uh get that ready to go. Um we did a lot of looking at versions trying to decide whether to go to 11 or 17 or 21. Uh we've been looking at like the closure survey data and what other languages are doing [snorts] and uh we've decided that there's really no point in moving to 11 as a baseline. It's are also basically end of life at this point. Um and so 17 seemed like a seemed like a reasonable place. were basically then supporting currently three uh three LTS JVM releases. So that seemed like a good compromise point. Um when we uh made the changes to move past it, we discovered that the existing bite code emitted by uh closure does not validate with the verifier updates that had been introduced since Java 8. And that's because they have tightened up some things. There's some one of the restrictions that has been in the spec forever is that you can only initialize static final or not stat final fields from yes, it's static initializer, I think. So you can only initialize static final fields in the static initializer and and we had some stuff to uh push that out into helper methods which is uh technically not allowed. And so uh that technically came back to bite us as we move forward. Um so we did some work to evaluate options and and uh have slightly modified the bite code emitting uh to address that. It doesn't make any of the older classes invalid um as far as we've been able to see. Um so old compiled code is still fine. It's just compiling the new code that where you run into the problem or compiling code with the new JVM that you run into the problem. So uh I've done all the work uh to move to Java 17. There's a bunch of additional like issues that you look you run into like the Java do support uh you know has things hardcoded for JVM versions. The reflection stuff the um the security manager is a thing that they're they've deprecated or in the process of removing from Java. Um the imports that we autoimp import with uh Java.lang lang. Those have changed as they've added new classes. So, we've been through and evaluated all that stuff. There's actually more tickets than I have listed here. There's a bunch of them. Um, but those are basically all in our current uh pre-screened bucket. Um, the uh pre-screened tickets is kind of the main Let me drop out of here. See if I can drop over to pre-screened. Um, so, uh, in our process, um, once, uh, things come in the door, we triage them, decide they're worth working on. Um, uh, we work on those, uh, look at patches, develop patches, clean up the tickets, do all that kind of stuff, and when we think they're basically ready for Rich to take a first look at, um, they end up in this pre-screened, uh, report. You'll notice that there are a lot of uh a lot of tickets in here. There's 42 um tickets in this report at the moment. Those are all things that I think Rich is ready to look at. So, at some point he will look at all of them. That includes all that Java stuff, but also a bunch of other stuff um that we've looked at. Uh [clears throat] you may find your your favorite Jira in here as well. Uh potentially this is a public report. I I just I dropped it in the thing. We can post the links later, but that's useful. Um, I do have another report that I also sort of manually maintain that is just a a list of things that I think are important. Uh, usually because they seem critical or because I see them coming up a lot, uh, or because they're highly voted on ask closure, things like that. Um, so they can get into this report for a variety of reasons, but these are all things that have not been pre-screened. So they're all things that I think are uh worth definitely worth looking at for closure 113, but have not yet, you know, do don't yet have a a good problem, good solution, good patch, good whatever. So um, that's just some inside baseball. Uh, I'll talk a little bit more about that in the next slide. Um, uh, and there's some more things to come, but I I'm going to not talk about those yet. Uh, Rich has some new ideas, uh, related to dstructuring and spec, and that's, uh, something we're working on. So, more to come on that. All right. Um, so if you want to get involved, um, and and look at closure stuff, I've kind of just given you a bunch of clues. There's a uh ask closure is is the entry point for uh for new issues. So if you have issues, please file them. Um if you are interested in looking at things that are out there and voting on them, that's an awesome thing to do. It's actually the most helpful thing that you could do is to surface things that you care about. And there are lots of things in there. So it's pretty common for people to file a question for me to find that it's a duplicate of something that already exists. And that's fine. I don't expect you to find all those. Um, I'm happy to ddup them as they come in the door. I'm aware of them more than mo any human should be. Um, so that's not a big deal. We expect the input to that process to be a little noisy. [snorts] Um, you can uh search through there. Uh, I dropped a link here of like for example the most voted closure issues. We also have uh Jared has a nice script that he wrote that um sort of scrapes as closure, pulls all the data out and builds a a sheet out of that that's a little more easy to search and look at. And we need to figure out where to put that. [laughter] I'm happy to share that. It's just uh I don't we don't have a good place to put it right now. So uh I will try to figure that out. Um I mentioned that 1.3 candidates report. if you're if you're like, "Oh, I would really like to go work on something that the core team cares about." So, uh that 113 candidates list is a great place to to do that. Um I didn't put the link here, but uh you should follow the closure contributor process. Um and I yesterday published a video that I actually recorded in 2022, uh which had never been published and I don't remember why, but there was no good reason for that. Um so I just made it public. Um, and that was sort of all about the process and, uh, sort of how you can help with creating tickets, screening tickets, um, doing those kinds of things and the workflow for how we work on things. It has way more detail than I could possibly share right now. So, if you're interested in this topic, feel free to do that there or to ask questions in uh, Closure Dev in uh, Slack. Closure and Slack. That's a a good place um that we will see them and can answer. Um I think the thing to impress on first is uh the most the most useful thing you can do is to help surface things that are important to you. That means not upvoting everything in ask closure but upvoting the things that are actually affecting you. Um and it's totally fine to file a question if you don't even if you don't know whether it's already been filed. that's totally totally fine. If um the next most useful thing is for you to uh help make a ticket better and that doesn't necessarily mean patches. The patches I care about less than I care about the ticket. I care about the problem description and um whether we've tried to brainstorm multiple alternatives to uh to working on it and then um we we can engage in the comments as far as you know trying to uh narrow down you know what what possible um thing might be a good solution to this and what you'll find is that uh there's not a lot of lowhanging fruit out in the the closure jurro system. Uh the lowhanging fruit is mostly uh has been picked, you know, and has patches on it and needs somebody to look at it to approve it really more than anything else. Um but there are lots of tickets that could be made better. And so all those things in the one through candidates list are good examples. If you want to look at things that I think are good, you go look at the pre-screened list, which is all things that I think are good enough for Rich to look at. So those are that's a great set of examples. Uh, so that's my uh my call to action pitch. All right. Uh, let's move on to flow. Was I gonna have focus? Was I gonna have you talk about this? I can't remember anymore. >> Yeah, I I can I can talk a little bit about it. I think that um it's been out there long enough that that people know about it. Um, Rich Rich uh came up with with Flow. Uh, how long ago was that? Was that eight months ago? Six months? I don't even remember. I think it was a year ago actually. >> Yeah. >> Yeah. Yeah. A year ago. >> Yeah. So, it's it's it's been in alpha for a while and and uh you know the the text says it better than I could, but you know, it allows you to uh separate your logic from your topology and I I I think it's really cool. I haven't myself use it in anger. Uh but um I I know that people have and and there has been some feedback on it and and Rich is has been using it for his own projects, his retirement projects. Uh and so it it is getting attention and and uh it it it has been uh in the the latest version of of uh core async the the latest alpha version uh hasn't been sitting around for a while but it's been sort of we've been working through uh virtual thread stuff there which which I'll talk about later. Um but yeah uh if you can please use it we would love the feedback um especially uh around the documentation. I I think that uh uh there there have been there has been some feedback around the density of the documentation. I'm not sure personally how to make that better, but feedback from from the community and and yourselves would would be uh would go a long way in helping us uh get to where uh the documentation can uh you can use that as a as a as as a an entryway into a core racing flow. I I know there have been some people that have provided feedback that we have not responded to yet. Um I am aware of that and those are people have made very useful um uh comments uh in a couple different places and so we're we're sort of do another round of working on flow been trying to get the virtual threat stuff under control first. Um, and I think other than some of the things that have been logged, um, the, um, one of the big things that we definitely want to rework before release is the way that input and output connections get wired together, both to add some new options and to um, reduce other kinds of options. So, um, that's one area that is still we know is in the to-do list before we get to a release. >> Yeah. And some design work has been done around that and and so we're pushing that through the pipeline currently. >> Yep. And then uh Jared worked on Flow Monitor. I'll let him describe that. >> Yeah. I don't think I've introduced myself yet on this call. I'm Jared Taylor. I'm the [snorts] third member of the closure core dev team. So flow monitor is it's like a dashboard for flow and it provides a visual representation of the shape and state of your flows. So it makes it flow if you have even a even a moderately sized one can produce a lot of large maps of data output that can be kind of difficult to get your head around. So this condenses it into a visual and supports injecting data and stopping and starting your flows. It aggregates errors coming out of them and let you filter through those. Um, one pretty cool thing that it does is it provides a visual of channel pressure. So you can see if there's any back pressure that's building up between flow ins and outs, which is uh pretty pretty interesting to see. Uh this is also going to continue to evolve as the the changes Alex was talking about to uh flow start rolling out as well. So viewers and flow give this a try and uh you know feedback's welcome on this uh this project as well. >> Cool. Um toss it back to focus. >> Yeah. So um we have been the idea of integrating uh virtual threads into uh core async has has kind of you know it's it's been in the ether for a long time and and so uh in in earnest we we kind of sat down and thought about what that might be like uh and we we came up with with a lot of uh good designs around how it integrates in with the go macro and and uh thread dispatch. uh and actually released a version of uh an alpha version of core async that uh that has uh that targets uh virtual threads uh and for the the the go uh infrastructure. Um let me step back for one second and say that we had pre-released this this functionality uh prior to that. uh the the latest full version of of core async includes an IOT thread function uh which uh if um uh the functionality as it stands is that if you allow your code to use virtual threads and you and virtual threads are available uh then uh then then IOT thread will use will use virtual threads and so the go macro uh was built sort of on the the same technology that IOTH thread uses Um but it turns out that uh virtual threads in in the JVM um are are are hardtracked. And what that means in practice is that um core async users are used to uh firing off go blocks uh and and just sort of you know forgetting about them and and so uh if if you're backed by virtual threads and your your your your go uh your your process runs to completion in in a virtual thread, no problem. You have no problems at all. Uh but what happens if the the the virtual thread does not complete is it it'll stick around basically forever. Uh and so uh there is a uh a feature in in the JVM that is hard tracking these and there's Alex uh actually went and uh communicated with the the the JVM team around this and and and this is uh a public discussion and and they gave a lot of uh justification for why it is the way it is and and and so I I won't relitigate that but uh the the the the gist of it is is But hardtracked virtual threads uh that that can't be uh garbage collected uh if they're parked waiting on something that goes away that itself gets garbage collected uh doesn't really work as a general uh purpose solution to uh backing a go a go macro with uh virtual threads. So we we thought about and thought about we it for a long time, you know, we we we were trying to come to a way of how do we how do we make it work, right? Can we can we add some extra infrastructure around how uh we're tracking the lifetime of a virtual thread? Uh and and it turns out that there wasn't a real good answer to that. And and in any case, uh the one way that we could avoid this hard tracking problem was uh was a CIS property that uh is not documented. Well, none of this is documented. Uh none of this hard tracking is documented, but there was a flag that allowed you to uh turn off hard tracking. Uh but the the Java virtual machine team has told us that they're not going to support that moving forward. So, we we couldn't even rely on that uh as as a as a way around this. So we just sort of did a bit of tactical retreat around uh their use of virtual threads uh and backed off of the idea of using them in a general purpose way inside of the go macro uh and instead of just isolating their use through to via this IO thread function. uh we had all this machinery in place around uh compile time checks to see if you wanted to use virtual threads and if you had virtual threads and and runtime checks and all of that goes complexity goes away. uh and and and so what what the the the new paradigm is that if you call uh IOT thread and you your runtime has virtual threads available virtual thread capability it will use a virtual thread and so that that's kind of where we landed and uh it's simpler uh and so maybe maybe we can come circle back around and and readress the the general purpose go problem in you know via another implementation or or you know new new features in the future but for now this is this is how we're going to proceed moving forward. >> Yeah I think that the things we were we've had to give up on are implementing go with virtual threads basically uh just not going to happen. So what what you know what what core async allows you to do when it's when it's using the IOC infrastructure is um if if a thread is is is parked if if a uh if it's parked on a channel and the channel goes away the data associated with that that uh parking operation is collected. It it it also goes away but that doesn't happen when you have it backed by a virtual thread unfortunately. Yep. All right. Uh some other core async improvements. These have these are mostly in the non-alpha versions of core async except for the last one I think which is still in alpha. Um but these are all uh performance optimizations or error handling stuff that we've uh run into and cleaned up. Um so those are just getting out there too. Um, uh, Jared, I'm going to have you talk about closure java doc. >> So, in contrast to the undocumented behavior of vthreads that focus was just discussing, this deals with uh, Java doc. So, this is a the the more documented side of things. This is a library that let you access Java docs in your ripple. um let you look up class descriptions and method signatures and return types and all that good stuff. Um it works with built-in JDK classes and also third party dependencies. So it takes the HTML and it's kind of two ways to get it back. It can come back as markdown or as structured data that you can use for more programmatic stuff or just bits and pieces. Um this has been out there. Some people have been using it. We've been getting some good feedback from folks who are uh actually trying it and using it in tooling. So if you uh want to give it a shot and have any suggestions [clears throat] for practical enhancements, this is uh something that's actively being worked on. Great. Um I'm not going to go through all these in detail, but this is just uh some of the changes that have happened in uh closure CLI and tools deps over the last year. a lot of bug fixes, some bunch of improvements. Um, there's a new library that is eminent. Uh, it's actually been released, but I haven't announced it yet. Uh, because I'm still testing some things. But I've basically pulled out a subset of tools depths. Uh, in particular, the subset that deals with uh, reading, validating, and manipulating depths Eden maps and put it into a new library called tools depeden. And the benefit of that is it has no dependencies. So if you need to, you know, find the standard depth chain files, read them, validate them, do stuff like that, you can do that now, uh, in a tool, um, without having to pull in all the Maven libraries and all the other junk that is in tools depths to do depth expansion. Um, so, uh, that is sort of a a lema that I've been working on for a while, uh, to allow me to add some new features to, uh, the Dupse Eden, uh, file and our data structure. And, uh, that's, uh, coming coming at some point, but, this was kind of a thing that had to happen first. So, uh, tools build, there's some, uh, enhancements and bug fixes there. Not going to go through all those. Uh, transit Java. Jared, do you want to talk about this briefly? Briefly, this slide hits it pretty good. We're dusting off uh transit Java got updated Jackson version that cleared up a security alert and uh some performance improvement around removing a cache that wasn't providing any benefit in the reader and writer factories that could cause some lock contention. Um and yeah, some automate automation stuff to get it up to par with some of our other repositories. There's also a new transit CLJ that the only change there is it uses the new transit Java. >> Yeah, these are the first versions of these libraries that have been released not on my laptop. So, [laughter] definitely progress. It's been a long time to do um so we we finally to did it. Um and then I think uh the other big dependency thing that needs to be done there is message pack. um which is a really old version that we're using out there that has had significant API changes in the interim. So it's a that's a bit more of a longer poll, but uh we'll we'll get there too. Um just uh some changes on the closure or site. Not going to go through all those, but just stuff we've been working on. Uh this is kind of important one. Um I'll just mention this Jared. Um the uh Zack Kim has been created closure.org or over a decade ago uh and was working on Closure at the time, but pretty soon after that moved into other areas and he's been uh people may have noticed that at times uh we stopped getting updates on closure.org and that's because uh Zach was off doing other things in his life and uh so he kind of hit a point where he was really wanted to devest himself of it and he offered us to take it over. Uh and so all of those assets have been transferred to New Bank. Uh closure.org is now running on new bank infrastructure. The domain is ours and the uh we forked the repo to a new repo. Um and uh Jared updated it to the latest closure and all Jared did all of this work. I didn't do any of this work. Um and uh we are planning to do uh some more significant updates in 2026. I would love to move it from uh its current database into Daymic for example uh and do a lot of cleanup and uh make it easier to use, easier to contribute to and uh all that kind of stuff. And uh I think Jordan's going to be spearheading that effort um soon. So that's come to be coming. And then I will let uh Kristoff handle talking about the task forces. >> Yes. So, uh, we have a we have a few small focused groups now that are meeting in a few different areas. And so, the goal of these groups is to bring together people in the community together with people on the core team to focus in a specific area that is strategically important to closure for the long haul. And so, we have a few of those. So one of those is a cross dialect collaboration uh between Rich the core team and other dialect authors. So that is including uh closure script closure dart closure CLR babashai squint cherry jenk. The idea is there's a lot of commonality there and in fact you can write code that runs across all of those and so the idea is to to collaborate and create a better solution overall through that collaboration in in making things consistent where it makes sense to make them consistent and making them different where it makes sense to make them different since that isn't always obvious. Thus the collaboration also uh we have a task force that is focused on tooling and especially like the closure CLI and looking for user experience improvements, developer experience improvements on that looking for how can we help people get started with closure uh simply on the install and the usage side. And so that's a focus group that is including um all of the key tool makers uh in the closure community. So we have um Phil Hegelberg in there, Michelle Borant, we have Alex, we have um others. So anyway, you um that is um something that we started up as a result of some of these work uh we had these um meetings at the Kunch. So the working groups of the college that organized and so that we got together we talked about the state of things and and figured out what areas really determined needed more focus. We determined needed more focus and then the final area is around supply chain security. We don't want supply chain attacks on closure and we want to make sure that we're securing our software supply chain. And so we have a small group that is also focused on um adding those measures. We're seeing that happen in other languages too. As you've probably heard, for example, you have Node. Um, npm has had a whole raft of attacks on it and some of these attacks are very sophisticated. And so we we want to make sure that Closure is protected against those and we're in a pretty good place because we control a whole bunch of that software supply chain ourselves and and so everybody who has a hand in that is involved in those. And I I think you could also mention that um we were able to leverage some of our new bank offensive security teams experience and they helped us out with doing some threat modeling and that's going to be sort of informing where we make additional changes and updates. Uh and I think that's it will be a great uh outcome for the ecosystem as a whole. Yeah, new newbank has a quite the first class team doing that because they have to operate as a bank and in an international context. So it's it's just been a privilege to work with them in helping with that too. >> Nope, I got to move the slide. Forgot. >> Should we go to the next slide? Okay, so we we have some upcoming events. So something to be looking for is the closure documentary. We announced this at the Kunch. Uh, we don't have a specific release date. It's still going through post-processing and editing and all that, but keep your eye out for more news on the closure documentary. >> Sponsors still wanted. >> Yeah, sponsors are still wanted. So, if your business would like to help make this happen, um, a good chunk of the funds go into editing. And so, there's lots of footage, but you can only do so much editing. So if if you want to get more content in that documentary and and help it be a longer, richer work, then uh please reach out to me and I will get you connected uh with the company that's making the documentary. So definitely looking for sponsors. Would love to have more. Then we have a few conferences coming up. So one is online. It's a closure jam. And so think of that as a festival more than a conference, right? It's a celebration of music, generative art, creative visualization, creative expression through code. Uh you love reppling and closure, you love the dynism of closure. And so closure jam is a celebration of all that. And so uh that is being organized online over a couple of different weekends. Cyclloge is the organizer of that and you can find out more information in the deref. You have links to all these. There will be a dref coming out today. It comes out every Tuesday and then we have uh two conferences that happen on subsequent days in Amsterdam. So Babashka comp and then Dutch closure days. So Babashka comp is very much focused on Babashka people who use Babashka advancing Babashka but bringing the Babashka community together. And then clutch uh Dutch closure days is really about bringing together the closure community and enthusiasts there in the Netherlands and beyond um to to celebrate co closure. So each of those are one day events but they're one right after each other. So you can uh find out more information about those online. That's it. We're up to the Q&A. Okay. So, if you haven't already uh posted a question and you want to, now is your opportunity to click on the Q&A button there at the bottom. And we're looking at questions. Uh go upvote questions, go post questions. Um Alex, do you want to you want to pick you want to pick the ones? >> I cannot see them because I am sharing my screen. [laughter] >> Okay. >> I can't see >> the top question. I will read them. Top question. Who >> I got it. >> You got it. Okay. >> Yeah. Hopefully you can see it too. Who is the closure core team? So everybody on this call and Rich and then there are a couple of additional uh members of our team who are on the closure team at Newbank, but I I would say are not on the core dev team. It's kind of a so there's kind of a a rough uh approximation here that uh we have Magda Uslio who's on online as well and she uh runs the KJ and helps with lots of other things as well. Uh she is currently working on a new um closure meetup support strategy which you'll be hearing about very soon I hope and uh closure south and other things like that. Uh, and then Jordan Miller is also on the team and has uh she's a a recent addition and she's she'll be working on external events and creating closure content, closure.org, other things like that. Tools analyzer JVM. Is this still true? I know we did a bunch of the work for it. I'm not sure if um Nicola has actually reviewed all that and released it yet. >> Yeah, so there was there was some work on that. Uh I had I had worked uh in the beginning at least uh uh with the with the team and and I know that uh Nicolo was looking at it and and and I believe Ambrose was too, but I don't let me don't quote me on that. Uh but it it had made some progress and and and I'll put an action item down to follow up on this and figure out where we are there. >> Cool. >> Um which dialects? I think Kristoff, I think you answered this. I don't know if you want to answer it again. Yeah, I'll I'll just run through them. So, Closure, Closure Script, Closure Dart, Closure CLR, Babashka Sai, right? Size technically the dialect, but Babasha is what everyone's heard of. Also, Squint and Cherry, which are related, and Jenk. So, those are the those are the ones I'm also I talk to other authors of of dialects that are um you know, under development, too. So, I'm always happy to talk talk to anyone who's making a closure. >> All right. AI, good question. The answer is no. [laughter] That's the short answer. The long answer is that um I I I don't honestly know how I would use AI to make my process any better. Um, we spend so much of our time trying to decide what we're going to do. Like I don't know how I would use a AI tool to act using an AI tool to actually make the patch or whatever is really like the patch is usually incidental once we figure out the hard thing. And I'm not sure how I would use AI to figure out what we should make next for closure. So, um, uh, I was just, you know, have been working on this tools depen over the last week or so. And so, I've been doing a bunch of coding and making a a ton of decisions as I sort of move code around and tweak APIs and do all that kind of stuff. And I I'm thinking all the time about, you know, how is this decision going to affect people from a backwards compatibility point of view? and how does it how is it going to um cut off or open up options for us in the future? And I a don't think an AI would actually um be able to do those things unless it was instructed to do so. And b I don't know how to instruct it to do so in a way that's useful. [laughter] So maybe I'm just a lite but uh in this particular case I I we do use AI for other stuff and I certainly use like chat GVt and I use it for you know especially for like building utility things that are you know that uh I don't really care about maintaining it or the quality of it particularly I you know I find it useful for things like that sometimes you know I forget how a thing works in Java so asking a chat AI you know how a thing works in Java give me some examples of it. Like that's useful. So I use it in that way, but I I don't really we don't really use it to decide what we're doing or to do it. So um Kristoff, I'll let you take this one. Sure. Has the tooling working group had any meetings, etc. since the Kunch? I don't want to be left out. So the answer is no, not yet. Uh what happened is the CLI uh task force kicked off from the tooling group and is getting most of the attention right now. I'm trying to, you know, free up more of my time. Um I would love to look at that a little bit more broadly. Um I've continued a lot of one-on-one conversations with people who are involved, but no, we have not had a tooling work broad tooling working group um since the Kunch. And then there's another one there, Bassilisp. Yes, I have talked to Chris Rink. Um, I've been talking to him. He started that as a hobby project that has sort of grown and grown. Um, that's one of the exciting things we've seen from the cross dialect collaboration. So, Jay Wilkerson, the author of Jenk, kicked off a test suite that tests a whole bunch of the core library in your dialect. And so I got Chris and Jay connected and so he could start benefiting from that. So yeah, Bassilisp is is on the radar and um but it's also the different closures have different levels of resources uh committed to them, different dialects and so we try to be sensitive with people's time too. >> Uh yes question about um extending dependent. I'd say that's a solution. Um, but it is a solution to a problem and there are several related problems with ways to um, use Depeden in multi-RO scenarios I would say. Um, and I think there are multiple solutions to those set of problems some of which solve some of those use cases better than others. Um the uh moving things out into uh tools depeden is sort of a first step that needs to be done so that toolmakers can rely on that like if we add new features to depeden I didn't want people to have to sort of recon like if we're starting to be able to to pull information from multiple places either inside a depeden file or depeden data structure or by aggregating multiple depeden file file somehow you're going to have to start doing some more computation as a tool user of DUPS Eden and so I really didn't want to leave those tool users out I wanted to make um a good library for that sort of thing which the you know the nent part of it was there inside tool steps but it had all these extra dependencies so splitting those things apart was kind of a first step um and then the next step there is to try to figure about which of those features um can usefully solve the problems that I'm aware of and uh I have not decided yet but I've been thinking about it a lot uh and hope to make progress on that in the next 6 months uh sort of in tandem with work we're doing on the CLI. So uh Kristoff didn't mention this but like we've been I've been working heavily on doing design work for a new version of the CLI. um it uh will continue to work with all of the things that work now. So um not trying to make anything that breaks anybody, but I would like to make it uh much more easier to use. And then we've also been trying to investigate how we can make it more reusable for um other dialects as well potentially. And so um the CLI task force has been talking about those things. will be meeting again soon. Um I think I have some interesting design there but the uh uh I would like it to be uh have the the simpleness of uh deped now uh and but more the easiness of Lenigan or something like that. So certainly a goal is to be able to support new projects and new users better. So you can say something like CLJ new, right? and to support things like CLJ test and and to to make those uh be a set of commands that is uh expandable uh both by toolmakers and by users and um uh so fig figuring that out and making that work in a way that is uh you know backwards harmonious and all that uh is kind of the the crux of it u but I think we're on a good track there. >> Let me let me just jump in there. Yeah, because that is part of a collaboration. So that's part of the CLI task force is to make sure that that's done in collaboration because we don't really want to design it in isolation since tooling, you know, is situated. And so um so people in that task force you know include like Phil who worked on Linean and created Linigan and MueL Borant and and so it's just important to solve these problems as as a group um as we as we move forward. >> Yep. Uh next question on how closely do we collaborate? Um we have a regular meeting every couple weeks where we talk about issues. Um and the atomic team surfaces things to us uh about closure or core async or other libraries like transit. Um so I mentioned the one thing that came from datomic but there are a couple other things. There are several other things in the core async list that came from the Daytonic team. The transit stuff was raised by them. Um, so they've got people that are looking at um our new bank services, which are super heavy users of all of these things um and trying to find problems that are related to uh unnecessary allocation or um performance or contention, lock contention. So, uh some of those are a little harder to see, you know, when you're down in the weeds of a thing, but they're looking at whole service stuff. And so um they have just a bigger context and a more application focused context. So I think that is a way that um the closure and data communities are are getting really significant wins out of uh new bank's use of both of those things that it's not obvious but um it is sort of driving you know changes that we're making and improvements that we're seeing. Yeah. Uh Arthur, yes, we were hoping to do this regularly, probably every quarterish. So, uh next question about Windows next two questions. Um so, um yes, I hope so. Um I don't >> I was going to jump in and say if you would like the Windows story to get better, please talk to me. Um I'm looking for people who are fired up and passionate about making closure on Windows great. And so, um, please talk to me if you are interested in Windows being a wonderful experience. >> Yep. Um, yes. So, as far as startup times, yes, I would definitely interested in working on that. Um, I'd say that's potentially in scope for 113, but, uh, it's not something we're actively working on at the moment. Um, but yeah, definitely would would be interested in that. I'm a I'm aware of uh lots of issues at Newbank in this regard. So, uh it's definitely high on my high on my list as far as uh problems to work on >> and and JDK 25 does improve things just out of the box. So, if you're not already using Java 25, um you're you can get some improvement further just by switching that to that too. >> Yeah, Java 25 continues to amaze me. It is significantly better than 21 in every way that I've managed to measure so far. Uh and uh often I find it to be shocking when [laughter] I do a Perf testing. If you're not using Closure 1124 and Java 25, I would recommend that you get there uh because it's better. All right. Well, we are at time past time. So, I think we should wrap it up now. Thanks everyone for joining and uh hopefully this was useful. Feel free to send Kristoff all your feedback and then he'll he'll assemble it all into one crisp sentence and deliver to me [laughter] >> using using AI. >> Yeah, that'd be great. >> Yeah. Thank you so much everyone. Thank you.

The Clojure Core Team discusses what they've been up to and things coming up soon. This is the first of what we expect to be periodic (quartertly-ish) updates from the dev team.