The State of Amper | Joffrey Bion

[00:00:00]Awesome. All right, let's get started then. Welcome everyone. Uh, welcome to my talk about the state of Amper. I hope you had a great lunch and that you spent your little nap time during the two previous talks. Now you got the fresh batch of coffee for this one. So yeah, before we get started actually I would like to know how many of you are here because of the keynote announcement about the cotlin tool chain. Oh, not that many. Okay, how many of you knew about Emperor before the keynote? All right, that's cool. Wow, that's warm.

[00:00:28]That warms my heart. All right, great.

[00:00:31]Um, well, and how one last question actually. How many of you actually used Emperor in some project? Pet projects count like tried it. Okay, sorry interest. Okay, that's good. Well, um, my name is Joe Fion. I've been working on Emperor for about three years now and I've been working at Jet Brains for double that and I'm super excited to be here, super excited to talk about this uh, Amper initiative. So the the people who um paid attention during the keynote and know already about the cotlin tool chain thing, I will get to it. I promise. Just bear with me for four slides and uh I will get there. But first I'll talk about what Amper is or rather was and uh we'll get it from there. So what is Emperor? Um spoiler alert, it's not a Gradle plugin. It hasn't been for a long time. Uh if some of you heard about Emperor back in the time where it was a gradal plugin and never heard about it ever again, I suggest you get um you have a look at the dim savino talk from last year last cotton comp where he explained the transition quite well. But this is about emper the actual build tool like maven or gradel. So it's a build tool for cotlin that focuses on UX and tooling and uh I'll break that down for you. So let's start with um what a build tool for Cotlin is and more specifically a build tool. When I say build tool I mean the following there is it's a tool that first um gives some structure to your project defines the project the modules and how they relate to each other and it provisions what you need to build your project. So dependencies tool chains and all this then it actually does the work.

[00:02:09]It builds, compiles your file, runs the processors, annotation processors, KSP processors, code generation before compiling all this to do the actual work. That's why it's called the build tool. And after that, usually you want to check that everything works. You run the unit tests, llinters, report problems. That's how you integrate it into your CI or maybe maybe your reviews as well requests. And the next natural step is to package this compiler output into something useful for users and then share it with the world. being it um a library that you want to publish to Maven or maybe an application that you want to put on a CDN or something. So that's the main pipeline of what a a build tool usually is. That's what it means to build a project. But usually what we put behind the word build tool, it's actually a bit more than building.

[00:02:53]You want it to be the entry point to interact with your project. So you want to be able to run your application u maybe run with hot reload or live reload depending on the tech that you're using.

[00:03:02]You want to debug. You want to profile your app. So this and all of this with like caching and telemetry. So a build tool is a bit more than just build. I don't know why we stuck with this build term but that's what I mean a lot of things are going on here and we want to handle as much as possible.

[00:03:20]So that's a build tool but I said a build tool for cotlin and usually when I say this people say well cotlin is a lot of things. Cotlin is uh multiplatform so there's a lots of stuff there. So what do you mean when you say build tool for cotlin? So let's see what can Amper actually build and um let's start with the core of what Cotlin was or or is it's the Cotlin JVM world. So of course Amper can build JVM libraries. It can build server applications like Ktor or Spring. Um it can build desktop applications as well in console or even with a UI or swing for the for the wheel. Um but of course cotlin is not only JVM right cotlin is multiplatform.

[00:03:57]So when I say um that emperor builds libraries, it builds also multiplatform libraries. When I say emper builds um desktop applications, it can build also native Linux, Mac OS, Windows applications. And we can't talk about Cotlin multiplatform without talking about mobile as well. So it can build um Android applications, iOS applications, and it can last but not least also build web stuff with the cotlinjs or cotton wom technologies. Although I have to admit that this is still a little work in progress, but I didn't lie to you.

[00:04:26]can build it. It just can't run or test it. Who needs that, right? So, so uh we'll get there eventually, I promise.

[00:04:35]So, you can see you can do all of these individual things or you can do a little bit of everything together by uh using technologies like compose multiplatform for instance. And all of this is also built into Amper.

[00:04:46]So, yeah, back to our definition. Um I I'll still have to leave out the second part for now because we are now on the fifth slide and I said I would address the cotton tool chain thing on the fifth slide. So we have this um build tool which is a bit more than build for cotlin and for everything that cotlin has to offer as we just uh we've just seen. So we figure every everyone that builds cotlin projects actually needs something like this and everyone should have something like this and we figured with jet brains right we built both of these things we built emper and we built um cotlin the programming language and the compiler and tool chains and stuff.

[00:05:21]So why not make it part of the default offering so that when you are um downloading cotlin and you want to work with a project you get everything you need to work with a cotlin project that's why the cotlin tool chain was born it's a single unified entry point into cotlin so you just need this and you can do everything you need with your project and that means that with just one command to install it you can pick there's two here but you can pick one of them uh the package manager of your choice or just the simple script execution you get that installed on your machine and then you get the CLI with all the commands that you used to know for from amper you can just use that in your project as cotlin now so cotlin in it cotlin build check test run package you name it you get um everything there and we'll introduce more things because this is still all part of the the building pipeline that I showed you earlier but we intend to add more things like maybe LSP skills things that are around the build but not quite just building and this is already in alpha so emper was experimental how we make it part of this cult tool chain that will be a bit more than just emperor and this is alpha so it means jet brains is committed to support it you can use it you can try it we are eager to um get your feedback about this because we think it's really cool and we really want uh to know how to make it even cooler so like my people in back in France like to say emperor is dead long live the cotlin tool chain so actually thank you Actually this call this talk should have been called the state of the cotlin tool chain. So um hello everyone welcome to my talk about the cotton tool chain dejà vu right so the what is it it's a unified entry point into cotlin that provides everything you need to build your cotlin project and here it is again with a focus on user experience and tooling. So now I can finally address this last bit that I've been pushing for a while. What it what does it mean to focus on user experience and tooling for us? um it doesn't mean dropping everything else right when I say we focus on UX experience we care about performance we care about correctness very much um but it's more like a philosophy that informs how we think about new features how we design them how we implement them so let me try to break it down the goal is to be is for people to have fun and be more efficient and everybody says this but it's actually true uh and we are the first users of it we have we've been using Amper for a while now we using tool chain already for to build the cotton tool chain itself and we're having fun with it and and we care when we are not having fun to fix the problems and and make it so we have fun.

[00:07:57]So it's a bit selfish. Um so what do I mean by this? Let's get a bit more specific. We have the first thing I want to talk about is anticipating the needs of the users of this thing. Um and this is done via reasonable defaults and built-in features. And reasonable defaults give you the the fact that you have fewer required choices. You have less obstacles to get things done. We want if there is an obvious um choice between two things that most user will pick, then we'll just provide that if it's harmless. And built-in features mean fewer plugins, right? You don't need to download five plugins to get your library published to Maven Central because it's something so common that we really want to get it built in. So, let's see a few examples. Um here are some examples of the default that we provide with the cotlin tool chain. For instance, Maven repositories. A lot of people get started on a project, they don't they really don't care about the repositories themselves. They just want to add dependencies and Maven central often um provides everything you need.

[00:08:57]Google sometimes for some Android specific stuff. So we figure these are good defaults. You can of course customize it, but it's just one less choice to make, one less explicit thing to add in your config. We have also the default main class. uh if you you usually when you want to run a JVM application you have to provide this fully qualified name of a main class and when you get started if you just follow this main KT convention and you put a main function in it the cin tool chain will find it it will run it you don't have to specify anything explicitly in your config that's also one thing that removes some of the friction another point is default platforms so if you've not used the cultin tool chain before um when you define a module file you have product type that you choose the thing on the left here iOS app. So it defines what you want to build and then you have the list of platforms because cotlin is multiplatform you might want to build different things but if you choose iOS app most likely what you mean is you want to run this thing on iOS simulators and on the real device. So we'll provide these platforms for you. If you want to change that you can but it's like usually the default cuts it here. And last but not least default versions that's kind of the obvious um providing a default JDK version compos version.

[00:10:09]That's also what we want to do.

[00:10:12]Um, so that's about defaults, but you have built-in features as well that kind of go together with default. And this is um kind of a fun brag to be able to say, well, this uh module file is a oneliner and that's cool. We can build an application like this, but it's not real, right? Nobody writes this. Nobody uses this. So, let's make it a little bit more real um by adding some a few more lines. So, let's say you're building this spring boot application.

[00:10:34]you add a dependency on web flux here which you get from the generated catalog and that's what you write but what you actually get is more something like this so it's really small because there's lots of stuff there um but when you work with a spring project you want to enable a couple compiler plugins like no args all open compiler plugin you have some annotation processing going on you have some JVM compiler arguments there so you don't want to think about all these things you just want it to work and when you enable spring that's what we do for you because most people that work with Spring will need these things.

[00:11:08]So that's one example, but it's actually true for all of these built-in technologies that we have inside the cin tool chain. By the way, if I say emperor anytime here, I've been working with it for three years, so it's hard for me to just say the C tool chain. So if it slips, just forget it.

[00:11:26]So that's why that that's about the um anticipating your needs. when you that's like the goal is for you not to have to write configuration but obviously you have to write configuration at some point and when you do we want to prevent problems with early and actionable and detailed diagnostics so some examples of this is let's say you have um module file here it's an application and you have this setting JVM release how are you all familiar with the what the release setting means do do you know what JVM release It's basically um combine effect between the source target and API level. So source language the Java sources will have some language level. The bite code output will be at some level and the APIs that you can use like HTTP client or these kind of things that are in the JDK will also be limited depending on this value. So essentially this encapsulates like this is the minimum JVM my thing can run on. And when you say this and then you depend on a module that defines that its minimum JVM is 21, there's a problem here, right? If you're trying to run this application with that module that's compiled for 21 on a JVM 17, it will break. And the cotlin tool chain knows about all your modules. It's actually declarative. So very quickly we can pick up on these kind of inconsistencies in the model. So we'll see, well wait a second, this is wrong.

[00:12:48]So one of these three things has to change, right? So we'll highlight the different points that come together into a problem. Um you have this module my app. It uses this JVM release 17 but it depends on this other module that has a higher JVM release. That doesn't work.

[00:13:03]And the same kind of thing applies to other properties like this that are kind of transitive. So for instance, if you have this SDK library with some publishing configured, you want to publish it to Maven, you want some people to use it, and you depend on a module that has no publishing defined, there's a problem as well. If someone depends on your Maven library, it cannot pull this transitive dependency. It will break at runtime. So you also get this error of inconsistency in the configuration. So that what that's what it means to we get we detect these things early because they are um easy to find, right? It's just in even in the configuration, you can already see that there's a problem here.

[00:13:39]And the last one that I want to show to you is one of my favorites. It's uh sorry it's small on the slide, but it's it's so cool. I could not show show it without the the screenshot. So what happens is you declare a dependency here on cotlinx 14 core 1.8.0 and some of the other dependency in your graph brings for some reason a higher version of cines but here I made it a bit extreme by 180 but you get the gist.

[00:14:04]So some dependency brings 1102 and you want to know about this. It's always like it's not a problem in general in your dependency graph to have conflicts in versions. uh it's it happens all the time and it's fine and the dependency resolution will fix that. But when you declare something here and it's changed by the resolution, then something is wrong. You you're lying in this config file because it's actually explicitly listed here that you wanted 1.8. So probably you want to say that you actually want 1102 or you want to fix some of the other dependencies so this conflict doesn't happen. And this is really fun. You can see the whole graph of things of dependencies that brought this new version for you.

[00:14:44]And if you're not looking at your different config files here and there, because we don't really need to look at them sometimes, you have this um sync tool window in the IDE that kind of aggregates all the errors and issues that you have. But you might ask, but what if I'm not in the IDE, right? And uh you're right, and you'll be happy to know that actually most of these diagnostics, the vast majority of them are on the CLI already. So it's not inspections in the IDE only. If you run the CLI, you you'll see these um errors as well or warnings as well. So some AI agents might be happy with this and can interact with it and act upon it to make them accessible enough for actionable enough.

[00:15:24]So yeah, we prevent issues early as much as possible and the last point is to try to be invisible and deep IDE integration is the way we found to to do this which is basically we don't want you to have to go out of your cotling code. So let's say you have this um sorry again it's a bit small in this slide but it's I really want to show it um to show the big picture here. Let's assume you have this cin scope um declaration or usage is an unresolved reference. you forgot the cortins library. You have this quick fix to add the cortins library, but what you see is just you apply the quick fix and then you get green code rather yellow, but that's just color theme.

[00:16:03]It's code that works. And what actually happens behind the scenes is that well you had a module file without the dependency. Now you have a module file with the dependency and that's why you have green code, right? But you don't see this uh in general and that's the idea. You want to stay in the contain code to not get out of your flow as you're writing things.

[00:16:20]So you can see that in other examples like if you're configuring this um Kato application you want to install some plugins in your Kato app you just type install you have some autocomplete that's nice you want to install coug you get there uh you don't see the module file changes you just see that your um code becomes green it's also the case if you want to use some new language feature that requires some experimental compiler flag we add the compiler flag for you behind the scenes and you get um you get the green code again And last example is opt-ins. Usually you see a lot of those. You have a lot of of options to fix such optins, right? You have this global scope declaration. It requires an opt-in because it's a bit delicate to use. And you can opt in at the statement level. You can opt in at the function level a little bit above.

[00:17:06]You can opt in at the file level. All of this is just annotations. So if you do it, you see it in your cotlin file. And there's no reason for the fourth option, which is opting it at the module level to be different, right? But this one needs a compiler argument in the module files. and you don't want to have to switch to that to go make your changes.

[00:17:21]So, we'll just do it for you and then you'll you'll see that it works.

[00:17:25]So, that's it. Yeah, that's uh that's what I mean when I say we focus on UX and tooling. We try to um feel in which places we need to um be present and in which places we need to be invisible.

[00:17:38]So, enough about the philosophy and all the high level handwaving things. Let's get into real features. So, what's new since last year? Maybe last year is a bit too much. I I don't have time. It's already Yeah, we have 26 minutes left.

[00:17:53]So, I can't cover everything that happened maybe from the beginning of this year, but it's already too much as well. Let's see quickly what we have. We had um customization of the JDK provisioning because we used to be only able to provide the JDK 21 hardcoded.

[00:18:06]Now, you can choose, you can make sure that everyone that uses your project will get the correct JDK and it's rather consistent.

[00:18:13]Um we have thirdparty compiler plugins.

[00:18:15]So now you can use coin or the new version of coin for instance or metro or test balloon. Um this is also built in.

[00:18:22]I don't have time to detail this but if you go to the docs you'll find that it's actually pretty simple. Another cool thing that was there is dependency insights. So I'm listing here all the things I can't actually talk about because I don't have time but I can't help but saying a little bit about them because I'm so excited about this. So this cotlin show dependencies is actually quite useful. It shows you the whole dependency graph of your project.

[00:18:43]And when you want to investigate a little bit what happened with dependency resolution conflicts, you can just filter that graph with the coordinates of one dependency and it will give you all the paths to that dependency. So you can know who won and why the the conflict resolution.

[00:18:58]So it's pretty interesting.

[00:19:00]One initiative that was very nice is the dependency graph caching and uh because of that we could enable the autosync.

[00:19:07]Why? Because um when we think about dependency resolution and why it's slow, we usually think about the the downloads of the files, right? You say, well, we have to download a bunch of P files, uh JAR files, put them on disk. But actually, um once it's already on disk, it's still a bit slow and because you still have to resolve the whole dependency graph. You still have to look at all these pump files to find the transitive dependencies, to resolve the conflicts, to build the actual graph in memory. And that takes time. And actually, we don't have to spend that time because A lot of the times you don't modify your dependencies. So we can just serialize this graph as it is and dialize it when it's ready. And that's what we do. And that's why when you change module files now it's just a couple keystrokes save and instantly you get the new model synced with your IDE.

[00:19:51]So your new module is there. You don't need to think about it and to spend time. And of course this only works if you don't change any of the dependencies. Uh that's a bit uh unfortunate. So we are thinking about improving things actually here. We haven't um released anything in this respect, but we're looking into options.

[00:20:10]And the idea would be to have some incrementality here. So even if you just bump a version or add a dependency, we can still pretty much reuse a lot of the work to resolve the graph and then just do the little bit extra that's needed.

[00:20:23]So we'll get there eventually. Stay tuned. We'll have something for you. Um other things I can't talk about is the ton of IDE improvements that we made. Uh quick fixes, main class assistance, you name it. There's a bunch of things there. What I can talk about though is the uh Maven Central publication preview and the plugins preview. So I'll spend a little bit of time on this. Let's start with Maven Central publication. And the reason why it took a little bit of time to get there. Um so as I said before, we really want to have built-in features for things everybody needs, right? So Maven Central Publication is one of them. When you have a library that you want to get there, it's it's a lot of little moving parts in Maven Central and we want to make that easy. So the reason it took some time to get it is that because Maven central has a bunch of requirements for you. It requires you to sign your artifacts. It requires you to provide a bunch of data in your pom.xml that are mandatory licenses SCM URL developers these kind of things. Um you need a sources jar, you need the Java jar. So there's all these requirements and we need all the corresponding features in the coffin tool chain to be able to cover this to enable you to provide this information.

[00:21:31]And last but not least, Maven Central is a bit special now. It requires you to publish through a different API than the regular um Maven libraries do. So when you publish to a normal Maven repository, there's some way to interact with it. With Maven Central, now there's a new way where you publish a big zip bundle through an API that's a bit different. So it needed also some special attention pair, but we got there. So how does it look? You can have this library module with a few coordinates here. Publishing enabled.

[00:22:02]That's fine. If you want to publish that to Maven Central, you just have to add one more line. Of course, you you need more than that. It doesn't work because Maven requires a bunch of things. That's the whole point. But you know about them and you can fix them and actually if you really want so you need to fix the signing, you need to fix the publishing of the sources and you need to provide a bunch of things in the pump file. You don't have to read all of the details here, but how you fix it is just you provide this in the qu file in the module file sorry. So you get the sign artifacts, you get publish sources and some information in the pom. Um so it might seem like a lot but it's actually quite condensed here and um we're quite happy with with the result here.

[00:22:44]So with one command then you can just do cin publish maven central and then the m the library is there. There's some subtlety here. There's a couple modes where you can actually stop in the middle to actually check your artifacts before releasing it. Um, so you can choose between the two modes, but it's a single command still.

[00:23:03]And this is just a preview. There's some polishing that needs to be done, but I would be happy if you try it and let me know what's wrong with it. If you find some difficulties, especially around the credentials passing, we'll improve things about how we pass credentials there. For now, it's a few environment variables, but it's not for everyone.

[00:23:20]So that's from Maven Central. Um we also have plugins to talk about and that's a lot that's a big feature that was demanded by a lot of people. Um because well we can't as much as we want to provide everything builtin there are things that you can't provide builtin and plugins are an important part of that.

[00:23:41]So what can they do? Um why do you need plugins? The idea of a plugin is to plug in the system, right? So you need to get information from the build and then contribute back to the build. And the kind of information you can get from the build is the sources, the resources, the um compilation outputs. Maybe you want the jar. You can get also like random files on your disk or even Maven dependencies.

[00:24:03]You get some coordinates. Um cotlin tool chain resolve these dependencies for you and then gives you the jar. So as a plug-in author, you get the the jars for each of the dependencies. So that's the kind of input you can get and then you can provide back to the build some generated sources or resources classes even C interrupt definitions. Now we have C interrupt as well and that's how you contribute back to the build. That's when you want to insert things inside so you you are part of the compilation.

[00:24:32]But there are some things that you want at a more at a higher level. And for instance you might want to add custom checks. So if your plug-in is about writing a llinter or wrapping a llinter like Katy lint or detect you can provide extra checks and this cotlin check command runs all the checks in your project including tests that are part of it but also all the custom checks of the plugins. So this could also be binary compatibility validation for instance or llinters in general. That's a good use case for this. And checks are one thing but sometimes you just want any custom entry point for your users as a plug-in author for your users to get something done. So for instance, if you write a plug-in to generate um a change log, it reads issues, generates a change log, that's how you would do it. So you expose a custom command that's effectively some sort of public task.

[00:25:22]Um, and then the users can just do cotlin do and that command and run it.

[00:25:27]So the idea here is that the the little units of work inside your plug-in what we call the tasks are not necessarily public, right? It's not necessarily entry points that you want to expose to your users. Um, what you want is be intentional about this. So you want to add these custom commands um on purpose and choose which of the tasks you expose. So we'll see a little bit how it looks like. So what's um What does the a plug-in look like? Actually, a plug-in is just a module like any other module.

[00:25:57]Um, you can have for instance your app, a utils module. And let's say we add a build config plugin to the project. So, you have this extra module. The layout looks a bit like this. We have your module files. Um, what makes it a bit special is you have this extra file called plug-in.l.

[00:26:13]And what's in the module file? It's just a simple product type JVM amper plugin.

[00:26:19]Yeah, it's um it's in alpha. We know there's a bunch of things that may change. This is definitely one of the things that will change because the name is uh a bit outdated now, but bear with me for a bit more. So, this product type is to create your plug-in module and as a module of your project. Actually, this plug-in can depend on other modules of your project and that's uh it seems it sounds simple like this, but actually it means a lot. It means there is no meta build outside of your build. We don't prepare the plugins. We don't build the plugins before building your project. We build all we need as part of the same task graph. And that means you can reuse the same module for both your project and your plugins if it doesn't create a conflict or an actual cycle in the tasks. And it also means you can technically apply apply a plugin to itself um if it doesn't involve like changing the compilation for instance. So if your plug-in is about generating some extra documentation file, why wouldn't you be able to use it in your own plug-in? So you can apply a plugin to itself. That's um that's a fun consequence of it.

[00:27:26]So to use your plug-in in your project, you have to add it in the plug-in section on your project YAML file. This is how you register your plugin to the build because at first it was just a module in your build. Maybe you just want to publish this plugin. You don't want to use it in your build. So here is the way you use it inside your project.

[00:27:43]And then in each of the modules you can decide to enable that plug-in and get all its all its tasks and all its work that it proposes. So the checks and the commands and everything.

[00:27:55]So let's have a look at this plug-in yaml file because that's basically the core of what a plug-in is and what makes it different from other modules. So what's in this build config plug-in yaml? Essentially um tasks. So you you will provide these units of work and you declare them in this uh declarative manner in plug-in YAML by saying okay I have this task named generate config object the implementation is this other this function in cotlin so you will write the implementation of the task in cotlin it's called the task action and it's just a fully qualified name of a function here so this function is defined in your cotlin code it has some parameters the parameters you can provide and wire in the build directly from the yaml So it takes two parameters here properties file and config object output here. So the the role of this task is to read a properties file and to generate a cotlin object with the properties in it. So you can use it from cotlin. I won't show the implementation of the task. It's pretty trivial. It's just about generating the cotlin code that corresponds to properties. But um we need to save a little bit of time. So this is this is actually how you expose the task to the build or at least how you declare the task as part of your plug-in and then to actually say what your plug-in contributes to the build. You say well by the way this task what it generates is sources that need to be taken into account in your compilation.

[00:29:16]So you say I'm generating sources here is the language here is the directory that contains the generated sources and you don't have to wire any compilation task or wire these dependencies together. you will just say that this is what I contribute. So when you read the plug-in YAML file, the the consequence of this and the reason why it's no longer inside the um the tasks list at the top because it used to be there is because when you look at it, if you just hide the tasks block, all you see is the things that will be contributed to your um modules build. And for instance, here it's the generated sources, but if you take the example of detect for instance, it's a bit more than that. So detect is for for those who don't know it's a llinter. It will analyze your project and provide um some errors or some messages about about what happens and it usually comes with two uh tasks. One of them will check the errors in your project and the other one is actually about generating a baseline of the current errors. So you can only report the diff between what you already had and the new errors. So you provide two tasks here. One to analyze, one to generate the new baseline. And the way you want them to interact with your build is through two different things.

[00:30:29]One is the checks. So you want to provide the analyze t task as part of the checks. If you do cotlin check then you will get um this analyze task running. And you want a custom command to be able to say well as a user I want to update my baseline now. So please do this. So that's how it translates to the CLI, right? Cotlin check will run the check here and cotlin do update detect baseline will just generate this new baseline file. So here again you see the checks and commands. If you forget about the tasks you see how the plug-in contributes to the rest of the build.

[00:31:05]Just like before we could see um this generated sources. Oh, that's a lot to go back.

[00:31:11]Should have thought about that before.

[00:31:13]So here you see generated sources and over there you see this um checks and the commands lots of clicky clicky.

[00:31:21]Here we are.

[00:31:23]So yeah I I don't have that much time to talk about all the little uh features that we had. Um and I prefer to a little to present a little bit what's coming next.

[00:31:34]So let's see our future plans. One of the main uh thing that we want to work on is improve the KMP experience because so far it has fallen behind a little bit and we want to invest in it. So one thing that was crucially missing actually it's the KMP libraries publication. So that's the first thing we will be working on. But there is also Swift package manager integration and swift export in general. So we want to be able built into the content tool chain to be able to add the SPM dependencies there and work with swift more uh comfortably. So that's one of the big things we intend to work on. And another one in the KMP story is compose for web and the wasn't story. So as I told you earlier, it's still work in progress. We can't run things, we can't test things because we don't provision yet runtimes for the JavaScript stuff, but this is coming.

[00:32:21]Another thing that we want to work on is the compatibility between the IDE plugin and the CLI. We want it to be a bit smoother because the IDE at the moment is actually deeply integrated because it depends on parts of the CLI itself. So the CLI is kind of an application that has lots of modules in it and these modules can be reused directly in the IDE and that's why you get such a nice integration. But we want to introduce some some layer in between so that you can use the IDE plug-in with different versions of the cotlin tool chain because sometimes you work on different projects and sometimes these different projects have different versions. you can't just choose the IDE with the proper version all the time. So, we want to work on this to make it easier.

[00:33:00]Another thing is to make it a little bit smoother to install. So, we already now have um a global installation of the cultin tool chain which we didn't have in Amper. Now we have it. It's via SDK man that you can install it or you can install through a script but it's a bit better if we can provide it through the regular package managers that you might be used to. So, that's one of the things we want to work on. And last but not least, performance.

[00:33:23]We aim um for cotton tool chain to be quite easy to work with and one of the things that we really like is this autosync and the way that it's fast and we want also that for the CLI as well because agents need to talk to the CLI and run a bunch of commands and we we don't want to pay the price of an of a slow startup there. So the slow startup might be solved with a native image for instance. That's one of the options we're exploring. So maybe make the cotton CLI much faster using VM or something like this. Another aspect is incremental cotlin compilation because for the for the moment we are doing compilation avoidance. We know that if a module doesn't change we don't have necessarily to recompile the dependent modules these kind of things but if it's slight changes in the code that don't change the API then we can do even better. We can avoid compiling more stuff. So be more precise in what we compile here. And with the build tools API, we have a lot of things that we can do. Now, if you heard about the build tools API in the keynote, for instance, there's an effort, a general effort to consolidate this kind of features for all the build tools consumers. And we are one of the consumers of this build tools API. So we will actually use that.

[00:34:34]We already use the build tools API for JVM compilation and it will soon provide also support for the other platforms. So we can expand the use of that.

[00:34:43]And last but not least is the incremental dependency resolution that I talked to you about earlier. So we want resolution to be fast because that's one of the slow bits and it can be fast if it's incremental if you just change a little bit of versions or some libraries.

[00:34:59]So that's it. Um a few takeaways here.

[00:35:02]The cotlin tool chain is your new entry point to cotlin. It covers all you need.

[00:35:06]So please you need to try it. This is it has great IDE integration. It's in the alpha phase. we are going to support it.

[00:35:13]So yeah, just um just get started uh follow this link. You can install the cin tool chain and um play with it. We are really eager to hear your feedback and make it even better.

[00:35:27]Thanks a lot everybody. I hope you liked it and don't forget to vote.

[00:35:35]Thank you.

[00:35:37]Um, we still have a few minutes for questions if there is any. We have nine minutes left. So, thank you.

[00:35:54]Hey, um, thank you so much for the talk.

[00:35:57]Um I was wondering I I've seen other languages going through a similar path in which there's a lot of build tools that appear and then one um standard emerges for example with Python that they uh converge to pi projectl right so in the morning I've been to a talk by the gradal folks talking about how they want to go declarative and now we are talking about another way of doing declarative builds uh for cotlin um tool chain Um so have you thought of standardizing somehow so that for example it's going to be easier for the d the tech fellows or kit link uh kitlins that are having to keep um maintaining different plugins uh for different things or even for people to migrate from one build tool to another.

[00:36:47]>> I see that's a great question. um we are trying to extract the bits from the different so first of all we want to support all of these build tools right we don't want to replace everything um it's always useful some build tools have some pros and cons and different ways to approach things so we want to support all of them and we're trying to extract the common stuff as much as possible that's the build tools API for instance so there are things that we at jet brains can control which is the compiler maybe commonization between native platforms so this will go in um build tools API but there not everything can be like not everything is in our control so we're doing our best to to minimize the repetition of the code everywhere but there are things that are fundamentally different and we cancel all of that so if there are some um some things like I don't know kilint as you said that have to implement different plugins for different things there there is usually a way to write these um tools with reusable modules and then just a little layer of adaptation for the different uh build tools and I uh we actually never discussed with the team some ways to align how this uh layer of adaptation could be standardized. I I don't know if that would be possible but it's an interesting idea. Um I'll check with the team if we can think about something there but we haven't to answer your question. We haven't yet thought about this. Yeah.

[00:38:09]>> Cool. Thanks.

[00:38:11]>> There's another question here.

[00:38:15]Oh, hey.

[00:38:19]Um, Amper gets better and better every year. Thank you very much. Really appreciate it. I love it. Uh, use it for personal projects. I would love to push it forward with uh my company corporate usage. I think it would be pretty sick.

[00:38:32]Uh, my question is are are the artifacts produced by Amper reproducible or not?

[00:38:39]>> They should be. Do you have any problems with this specifically? Do you know?

[00:38:43]>> Not really. I was just >> the way the way we built sorry to interrupt the way we built the jar uh we already took into account this uh like the the time stamp story the different aspects of building a jar that could make it non-reproducible normally it should be standard now so if you face any issue with this uh don't hesitate to let us know we have this um slack channel it's still named emper I think in the cotlin slack maybe that will change but if you face any problems like this we'll be eager to to hear about it because that's something that we care about and um especially all the the caching story we want things to be fast so if things change all the time that doesn't work right and we want to have some reproducibility that's also why we had this effort about the JDK provisioning uh so we can pin the JDK to some version for instance and yeah reproducible jars is also something that we care about so normally it should be that's the answer if you find any problems let us know >> firstly thank you and um had his promise from two years ago finally coming true.

[00:39:45]It looks like um two questions if you don't mind. One, in the end, can I just fall back to the command line? Can I create a um a plugin that basically just says, well um I need to invoke this bit of bash.

[00:39:58]>> Sorry, can you come again?

[00:40:00]>> In the end, if I want to build a plugin, can I just invoke bash and say run this and it will output stuff into here?

[00:40:06]>> So the the way it's written right now is that you have to provide a cotlin function, but this cotton function can call anything. You can start a process if you want to. There's no direct uh bash call from the YAML declaration to this. So you have to go through cotlin.

[00:40:19]At the moment there's no cost to that because this cotlin invocation is directly in the same process as the emperor process. This will probably change especially if you go if we go gravm for the sorry emper process I said cotlin tool chain the cotlin cla process actually because the tool chain is more not an application but the cli process that runs the plugins directly. So you don't get this extra cost. You can just start this process yourself. We will most likely make it easy to uh implement plugins by providing some nice libraries. There is some uh APIs that we're thinking of in terms of the the cotton code can like feed back into the cotton CLI saying well by the way I have this report this diagnostic that I want to report this kind of things. to to send back information. So for this we need some tighter integration. But for other things like starting processes we can just provide some helper libraries that you can choose to use and make it a bit simpler to invoke a bash script if you need to. But why do you want to write bash?

[00:41:20]Um one more um amper used to be a build tool for cotlin and java.

[00:41:26]>> Yes.

[00:41:26]>> So now the cotlin tool chain is a build tool for Java.

[00:41:30]>> It's um It's one of the little nitty-gritty details here. Uh we still do support Java actually. It's just not the main uh concern of it. So I don't I don't mention it as part of the definition because especially at Cotlin comp, but it's it's still there. We even have incremental compilation for Java already. Uh but we don't have it for Cotlin. That's funny. But but it's u yeah it's there. It I don't think we will get rid of that. There's no point in that. It will be supported. It doesn't cost a lot to support it. Um but I I don't want to commit too hard because it's easy to say things on stage and then I'll get beaten back home and saying why did you say that? Um but yeah there's no reason for it to disappear.

[00:42:10]So we do support Java. It's just like um pure Java projects for instance are less of a concern. So for instance by default you'll always get the cotlin standard library on your class path. And if you're building a pure Java project, that might seem a bit weird. And this is not something that we have in in our priorities to to make it different. Um, but yeah, but Java is supported.

[00:42:38]So you have a really really nice language cotlin and it's called cotlin tool chain now not amper but you're still using a markup language like yammer and you can make really nice DSLs with cotlin so why >> I expected this question Sorry.

[00:43:05]>> And I should have prepared more.

[00:43:09]But the the thing is we we thought we thought a lot about this thing. We we thought a lot about how to improve this uh configuration language. We definitely wanted something declarative because it's really really important uh for us that's the import in the IDE or even the tooling support is fast and simple to write and if you have imperative Cotlin code to declare your stuff it's always a bit tricky right and one of the aspects also of it is that you would have to run thirdparty code to even know what your project is about and that's the the nasty little pop-up window that you get in Intelligj that will tell you well do you trust this project? Yes. No. Do you want to trust all the projects in the folder? We don't want to have that because it's not necessary. You you can import the project without any risk. If it's just YAML, the YAML will not run.

[00:44:00]And so that's that's part of it. Um so that's why Cotlin doesn't quite fit the bill here. It's uh we could have nicer DSLs there, but if if we invent a new language that's also a lot of toil for other tools to integrate with it. If you write YAML, there are YAML parsers out there. If someone writes a dependabot support for the Colin tool chain, they they can just read the YAML file, right?

[00:44:28]If you start to create a new language, then everybody that needs to integrate with it will have to understand this new language. And there are some configuration languages out there that may or may not be better than YAML. Some of it is part of opinion based uh ideas. I would say it's um but but most of the time when I hear people's grievances with YAML, they are mostly outdated in our context. And but what I mean by that is that um we own the parser. There's no such thing as the Norway problem. There's no there's no such thing as these like type problems because our parser is type safe. It knows exactly the model of the Cotlin tool chain project model. We know exactly the different pieces. So we can fail in very nice ways. If you use it, you will realize well um that everything is type safe just like Cotlin. You will get the same warnings or errors there.

[00:45:26]And um so so the only real grievance that's still valid for YAML I would say is the whites space sensitivity and it is a big one. Um but I think it's mostly perception. So as we've we've seen yeah we've seen a lot of other tools using YAML there. I don't think there is um a chance that we'll switch to something else now because we've looked at it and the more we think of it, the more we feel comfortable with keeping YAML.

[00:45:56]As bad as it can be in some respects, it's actually pretty good. In general, it it kind of pains me to say it because I also don't like YAML that much, but honestly, having working worked with it for three years, it really is almost never a problem. Um maybe sometimes you press enter and you don't know where your cursor should be but that's pretty much that that's pretty much it. Yeah.

[00:46:19]So not cotlin. Yes. Not cotlin that's that's of course something we we thought about at some point but for for the declaration of the project model it it actually doesn't really fit the bill.

[00:46:31]>> Sorry for the long answer.

[00:46:33]>> It's fine. Thanks.

[00:46:39]>> I think we're almost out of time. Are we out out of time? Sorry, two minutes over time. So, I guess we have to stop here.

[00:46:45]Thanks a lot for coming and I Thank you.