Eclipse Theia in practice: Getting started and lessons from the field

This talk focuses on Eclipse Che, a framework for building cloud-native web-based integrated development environments (IDEs) and tools. Stefan Dirix, a software architect at EclipseSource, discusses how to get started with Che, shares practical lessons learned from the field, and explains the architecture behind Che and Theia, a customizable IDE framework. The speaker emphasizes the importance of using Inversify for dependency injection and how Che can efficiently integrate with both traditional and modern development tools. He also touches on the community aspect of Che, encouraging contributions and outlining the monthly release schedule for updates. Overall, the session provides valuable insights into building applications on the Che platform and leveraging its features for effective development.

[music] >> Yeah, hello. Um, welcome to this talk, Eclipse Che in practice, getting started in lessons from the field. Um, I am Stefan Dirix, um, a software architect. I'm working at EclipseSource. And I just looked it up, so I'm contributing to Che since 2020. And, uh, when I look at my what I do at work, so I like for 4 years now, uh, 80% 90% of my

time is spent either working on Che directly or working on Che based applications. Okay. So, uh, what will we take a look at today? So, we have will have a short overview about what Che is, uh, then how you can get started, and finally, uh, some lessons from, uh, shipping Che products. So, what is Eclipse Che? It's a framework, and it's a framework for building AI native

web based IDEs and tools. And based on this framework, there is the Che IDE. So, um, which is basically just all the extensions of Che into a one product. And of course, because Che is a is a framework, you can build your own, um, tools also on the platform. Finally, I also want just want to mention, uh, Che Cloud, which is also a framework, so it's not

a service. And uh, you can use it if you want to, um, uh, serve your Che based application in the cloud. What are the features of Che? There are a lot of features. Uh, >> [laughter] >> we will not go through all bullet points, but, um, yeah. So, there's, uh, the application features just for the infrastructure, and then we have all the features building on top of

that to deliver IDE features. Um, so I want to quickly show you how this looks like in practice. Uh, we will go to, sorry. Yeah. Um, so I'm starting here. This is the try online experience of Faya. Well, basically Faya hosted the Faya cloud and I'm starting the version where we included some C++ extensions. So, just to show you something different which you didn't see in one

of the many Faya talks before. So, yeah, but it's nice to show. So, basically you get all the features of an IDE. You have your file system, debugs, source control, whatever you want. And yeah, let's just do something here. So, let's just start debugging. Uh and hope that it works. Let's see. Yeah, so I prepared this when I was sitting there looking for Jonas' talk. So, maybe

I lost the connection now. Uh doesn't really matter. So, in the end you can try it yourself. You can go to try online and try to uh use the debugging in your like very likely more successful than I am. But what you can see is that you have to Yeah, you see there some I lost the connection. Let's ignore that. Uh >> [clears throat] >> let's continue.

Okay. Uh let's go back. So. What's very important and this is because it's a question which often comes up in the forums and in discussions and when you're on Hacker News and there's discussions there. Yeah, what is a Faya? It's just another fork like all the other IDE AI based IDEs and I just want to highlight that it's not a fork. Um and to just quickly go

through the main points. So, for VS Code only the core is open source while in uh Faya everything is open source. Um which is important with all this proprietary features that are coming to VS Code like they're the cooperation parts closed source. And we have VS Code is only controlled by one company while we are backed by the Eclipse Foundation and in the end VS Code just

wants to be a code editor which people then pimped up to be a full IDE but in the end it's still just focused on code editing. Uh Theia is a framework for building whole custom tools. Uh VS Code you can extend it a bit with predefined extension points but in Theia you can customize everything. You already heard it so just the latest news so talking about this

that Sokrator and which is a tool from Samsung just released last month in March and in the same basically one week later the next gen tooling from STMicroelectronics was released and all the future chips will be supported by this tool going forward. Now enough of what Theia is. Let's get started. Um the first thing which I think if you want to start with something it's good to

know about the architecture. So uh we talked about cloud desktop applications and how does how does actually look like. And the main part which you need to know is that there's a back end side which is just a node based application and there's a front end side which is usually rendered in some in some browser and this is then connected via an RPC layer. So this is

how it looks in the browser environment. Then um we have also built-in support for Electron. So you get an additional process there and it coordinates the front end and back end and this is then all wrapped up in a package as an Electron application. Uh not to be forgotten there's also a browser only environment. So you can target just the browser. You have then a somewhat limited

experience. You're obviously missing the back end but you can much more easily host it because it's just a static uh web server is enough. Put the files there and you have your application. Okay, so let's go back to the to the basics. What's actually in the front end back end? What's in there? And the most important part is that each of them have an Inversify container. Inversify

is an injection framework and then basically you can when you're coming from an Eclipse SCP background, it's like the OSGi for Theia, just much more simpler and straightforward. Um yeah, and there you put in the Theia extensions. And usually you have to put in Theia core if you want to do anything Um put all the rest in there and this then brings in the the rest of

the rest of the determined dependencies. So for example, Lumino for the widget handling, React, Monaco in the back end you get Express. Um yeah. Then uh because Theia is compatible with with VS Code extension, uh there's an uh separate process running called the plugin host and in there there's all the VS Code extensions. And technically you also have one running in the browser. Um this is then

running the web extensions. So that's the architecture. What is What are the core concepts behind that? And it's that everything really, as a literally like 95%, I don't know, is uh wired via Inversify and you can then just rebind everything. So just a quick example, so there's the work space service and uh I want to replace it. That's all you have to do. >> [snorts] >> Um

then we have something which uh we call contribution points. These are just things where we already know, okay, adopters probably want to add some functionality there. So it's a foreseen thing which can even more easily extend. And for example, for the front end and back end, if you just want to hook up into the startup of the application, you um add a In this case it's a

backend application contribution. And you implement the on start and then you're already hooked up. >> Yeah. And these extensions are then included at compile time into the your fair base application. So, now with all the architecture and background out of the way, you now sit down at your laptop and you want to start. How do you do that? And the good news is you need one tool,

which is called NPM. And then you need one file, and that's it. Yeah. And you just start your file. You call it my application. Then you add your target. For example, I want to target the browser environment. It's the default, so you can even omit this. Um then you add all the dependencies which you want to have in your application. So, I just selected some of the

fair extensions. Um you can select from over 70 extensions which we provide in the fair core framework. Finally, if you already one step ahead and you already have some own extensions, you can also just include them there. Or for some third-party like Chelsper. Then you add the fair CLI as a dependency. And then you just need a build and a start script. And you execute a build.

You execute a start. And you're done. You have your browser-based fair application ready at your machine. So, but this Okay, there's a CLI. What's happening there? It's kind of magic. So, let's have a quick look. When you execute a fair build, what actually happens is a little bit of source generation. So, we're looking at the list of dependencies which you just saw. We look what's in them.

And in there you can say, "Okay, I'm a fair extension and these are my modules." These modules are collected. They are then put all into one JavaScript file where all these modules are loaded. Then up the front end application or backend application is started and that's basically it. Um additionally, there's a webpack configuration and this bundles your application. So, with this webpack, we invoke webpack and then

you get your two bundles out. This case for the front-end for the back-end or additionally for electron. And yeah, just as uh Thomas announced, so uh this part here will be uh gone soon and this part will be gone and then it's ES build. But, it doesn't uh doesn't change anything in the concept. that's it with the overview. You you know now what FA is. You know

how to start and now you probably want to know oh okay, so you do this for a living Um is there something which you can tell me? >> Yes, uh I can tell you something. So, let's start. Um ramp up. There's a lot of technologies involved, right? So, I just I put all the ones where I could find pictures. There are some where there are no pictures,

so they're missing, but I just put them out there and uh I'm just putting them there because especially in the FA world, many many people are migrating from older tools and they didn't do any web development at all. there's basically a lesson there. You need to consider the time to ramp up uh your developer plus that they are switching uh to this new tooling and which is

then a completely different world, so uh which takes just some time. Um even if you're already proficient in web development, you will be have a much faster time, but still you need then to know about the FA specifics. So, for example, in Versify, you might not have encountered that before, um so you need to learn how this how this works. So, uh you went up and then

you were uh uh want to know, "Okay, now I have this Fira base application, but uh what can I do now? What is the Fira way of doing things?" And the lesson here is that uh for you to know is that Fira essentially is much slimmer than it might appear, right? You saw all these icons, you saw uh architecture and build system and so on, but in

the end, it's just a web application. And uh in the front end, so in the widgets, um you get exposed a DOM node, and with the DOM node, you can do whatever you want. It's just the DOM. You can render arbitrary libraries in it. You can uh have the full browser API available. Also, there's no end uh of things. You can embed Fira into Fira if you

want to. it doesn't it doesn't matter. Um on the back end side, it's the same. Uh so, you get uh during startup, you get access to the Express server, which is in there. And yeah, do what you want. Add as many routes or APIs, services. Yeah, uh I mean, uh um it might be familiar, for example, with JSP. We even run JSP servers in the same process

on the back end. Doesn't matter, it's just Node. Okay, so that's the core takeaway here. Um another thing which but you also need to consider is that there are some things which are not covered by Fira, and you need then to provide them yourself. So, we don't have a packager for your Electron application. You get the You get the finest Electron application, but there's nothing There's no

installer. You don't get an MSI file on Windows to uh to install. Um there's no built-in update delivery. there's no foreseen deployment pipeline and so on. So, these are things which you need to solve. The good news is that um we had to solve these problems already ourselves. So, for cloud um hosting uh there's Flogo Cloud which you can just look at. It's open source, so you

can either use it or just use the same mechanisms. And there's obviously the Flogo IDE where also everything is solved and you can see it in source. So, there's a um repository for the Flogo IDE. Uh I think we're using Electron Bundler. It's also uh framework which just exists which you can hook up in and has very uh nice and convenient things to have updates and uh

bundling in the way uh solved for you. Um but you you you need to do it. Then, okay, you start your Flogo S application and then often they are very large, right? If you build uh these huge customized tools, um it's uh uh often as a hundreds of dependencies, um maybe a hundreds of your own and then thousands of other dependencies. So, it's not too uncommon. You're

you're mixing your Flogo extensions, you're mixing mixing VS Code extensions and whatever tooling you you're using in your web development. How do I organize that? And that's always the question, do I use a multi-repository approach? Uh do I use a mono-repository? And uh yeah, I mean, the the answer is not always easy, but I can give you at least a soft recommendation. So, from our experience, mono-repositories

usually work a little bit better. just because of the reasons listed. So, it's just conceptually it's simpler. It's much easier to reproduce things. so, it's just a soft recommendation. Might be Maybe in your organization it's not possible because of some uh rules and you have to use a multi-repo, that's fine. You can live with both, but um yeah, from at least from our experience, mono-repositories work a

little bit In the end, if you have a very large uh application, you need some custom tooling anyway. Doesn't matter which approach you take. Then FAY updates. So, you settled on FAY, but okay, how do I now update? How often does this happen? So, um FAY has a monthly release schedule. So, that's the current schedule, actually. And yeah, you can just uh update. And as you can

see on the versions, uh we're not following semantic versioning because it just doesn't make sense for a project of this scale. So, basically every single version would be a major version uh increase because we're exposing everything. Every method, every util, doesn't matter. Everything is either protected, public, uh so exported. Uh there's there's we're completely open. Um still, there's usually not an huge issue with that because we're

obviously uh still looking out for you and not just changing things willy-nilly. Um but yeah, so there's no unnecessary changes. And there if there's a breaking change, then uh there was a good reason for that. Yeah. Then there's also the community releases. So, they're every 3 months. Um and they're a little bit uh uh more stable in the sense that they receive backport fixes. So, when something

is discovered, for example, in July with the version wrong in May, um we still do a backport fix for this community release, and you just need to increase the patch patch level. There's really nothing in there besides like a bug fix. So, the um soft recommendation here is start with updating with the community and yeah, you you will realize yourself if it is sufficient or not. >>

For example, if you're uh using FAY AI, the development is just so fast, you usually then want to have a monthly uh update. >> So, I have to update. How can I be proactive about this that I have as less work as possible? And yeah, I talked about different things how you can extend the platform. And the best way is to use contribution points because these are

already foreseen things and they are really super stable. I can't remember that there was any change at all in recent times to an existing contribution point. But obviously, things which were not foreseen to be extended that doesn't have ex contribution points, so you do a rebind. Um or which is luckily never needed. I didn't see it. Never saw the need that you need to patch failure. Everything

can be rebound. So, yeah, I really never saw So, yeah, you usually can always find a way to to get your customizations into Now, you're doing a rebind. Um but you have to consider there that this basically a contract, but it's something which can break theoretically at some point in the future. So, here for example, the the workspace service was rebound and you're relying on the fact

there's this specific method which you over uh which you didn't override for which could change in the future. there you need to have some judgment. Obviously, I think a get default workspace path probably will not change in the future, so you should be fine with this rebind Um but there might be some things which were made a little bit clunky. Maybe you needed to rebind multiple services,

I don't know. So, always have it back in your mind and consider whether you can do the thing which is even better, contributing to upstream. So, um and this is it this we this always goes through. So, if if you need something to have a better customization, we just say, "Okay, this part should really be a contribution point." Okay, then just do it. And it's better for

Feya, it's better for you. And the good thing is that contributing to Feya is really really easy. why is this the case? Because we have a very open community. So, we're really encouraging you to do contributions. And we are helping you. We are doing code reviews. We will discussing with Um there's really a lot of effort, and this is not only when I say we, it's not

only Eclipse source, it's also all the other companies involved there. For example, I'm not sure if you see a mark saving a lot of there. Thomas is helping. So, um There's a really a lot of help there. And this then helps everybody. So, you are getting your changes in. You can easily extend. Other people can benefit. And if other people then do it, you benefit. So, it's

really good for everyone. And I just had a look at the discussions. So, there's really literally literally there's no unanswered question in the forums. Um so, you can try it. Yeah, go on. >> And then you have 20 new questions in the evening. Okay, maybe you have to wait then until Friday, but uh yeah. It's it's a really I think it's a remarkable point that a that

a community of this size still has this much support for free. So, there's no payment at all there. So, let's get to some other topics. So, it's hard to find a narrative, so there might be a little bit disjointed, but it's also pretty common question. So, I want to do this feature. Do Should I develop this as a Feya extension? Should I develop this as a VS

Code extension? And there's a very straight forward answer. And it is it depends. Okay, what does it depend on? So, use a VS Code extension. If you need the same feature in VS Code, I think it's a self-explanatory. Or you if you really need this runtime extensibility, then this is a no-brainer. Use a VS Code extension. Now, I want to also highlight the downsides of using a

VS Code extension. So, um you get a lot of friction in because you have to separate build of the extension in there. You have a much more complex architecture. Um We have an example there. Um and not to forget because it's easy to forget, you have a delayed startup. So, if your extension functionality is needed for your startup sequence, it will just take much longer. Um and

really the worst thing are web views because they are big and slow. Um you have to bundle all everything. You have a fancy UI kit built in somewhere. Um Uh you need to load all the resources every time you open a web view. You can't have them before that. They're they're iframes. So, you really consider that. And just an exa- quick example for the complex architecture. So,

when you have a fair extension, you just want to have some information from a service, you can just call the service and render. And then you go through a web view. Yeah, you have some messaging. So, from your web view single-page application, you have to do messaging to the back-end extension. You have to have some uh form of communication, for example, via commands, which you need to

have registered beforehand. This thing goes through the service, goes back to the extension, then via messaging back to your web view, and finally you can Yeah. Uh just as an example. You can have some libraries to help you there, but in the end, this is what you're doing. it's really often underestimated how much more effort it is just to get the message out there. The good news

is if you started via VS Code extension, it's easy to go to a fair extension, right? You're just throwing all the craft away and then So this uh we did this multiple times and this really straight forward. Okay, then another thing um you should follow the Fira architecture. I told you about it with the front and back end split. And let's say you're integrating another tool. >>

And uh what happens often is you already have a UI, you integrate this UI and this then has its own communication already baked in and you're just reusing that. So suddenly you're splitting here. Um this is usually not that good. For example, the extra port must be available in your cloud deployment, uh which you have to take care of. And suddenly you have a mess of communication.

So the better way is that you use the communication things which the path which was foreseen by Fira, which is through the RPC layer. So you can see it Um which is good because it's you have no surprise in your architecture and you get all the benefits of this connection because this connection is really good. It has life cycle management, it has buffering. If you lose a

connection, it's it's buffered and then replayed once you get the connection back. So um you get the benefits of all there all all of that. And there's a nice anecdote because we did this for a for a tool which don't I see here so uh I will not mention it, but uh we did this for some tool and we expected, okay, it's more hops, right? It's a

little bit uh farther away. So we thought the um uh performance would be worse. Actually, after really detailed measure measurements, it was faster to go the Fira way. And why is this the case? Yeah, you you don't have this additional connection which you first need to build up and the RPC connection is already there and it's not just some uh cheap thing, it's really a binary encoded

message pack and it just has a native node extension which through C code goes really fast to construct your JSON objects in the back end. So, in [clears throat] the end it turned out that this Feya was actually even more performant. things that are just also true, not only Feya but for every web-based development and you should never forget is that Java is single-threaded. And um yeah,

so the front end and back end has one main JavaScript thread. And this is easy to ignore early. So, you start your whole new IDE based on Feya, uh your happy greenfield uh scenario, and you're just uh coding away, and in the end it really bites you. So, never forget that there's this one single JavaScript thread. typical things you have to consider. So, if you're using like

an expensive UI kit, make sure that you don't re-render too often. Make sure that you don't block the critical startup path of of Feya. Right? We saw how easy it is to get into startup lifecycle, and if you then do a heavy work there, you're delaying the And uh something which is also uh easily overlooked is that even your back end can delay your front end. Just

a very quick example. So, let's say you do something on the on the back end and there's a very heavy operation, and the user does something in the front end and expects a response. If you don't have a mean way to to split up your back end work, the user has to wait until this back end work is finished, and only then gets a proper response. So,

um yeah, don't don't lose sight of that. um we saw that uh we uh with Feya, we support VS Code extensions. But, this compatibility is not for free. What I mean with that is that you really have to check whether your specific extensions that you want to use are actually working. Because, yes, we're supporting 100% of the API but just having the API supported doesn't mean it

does work. And what uh just one example what I mean with that is uh just was fixed last month. So, here in this case the pipe from unit test extension didn't work. And uh looking at the bug was that uh Feat when you called the um sorry, when you called the workspace folders API of VS Code returned sometimes a new URI object. It was the same URI.

Yeah, it was the same URI. It was just a different object. But this extension then used these URI objects in the map. So, there were suddenly keys in the collection. And yeah, then Feat this thing broke uh because uh yes, we are 100% compatible but we're also, and this is what we're aiming for, we also need to be 100% implementation compatible so that all the extensions work.

Um so, the the lessons for this is um if you rely on a third-party extension, then you always need to test it. There's no way around it. Uh the good news is that everything which people use is usually working because they quickly realize something's not working, there's a fix in Feat, and then it works again. Yeah, but there there are some extensions which are more problematic than

others. So, for example, GitLens is always on the they really like to uh dive deep into the VS Code internals. So, you often have to use a version one or two of the earlier than the current one because they just found another way >> to depend on some implementation Okay. Um then uh good point, I think, to to to everyone that at least from the feedback which

we get is that adopters are very happy with Feat. And these are basically the core points. So, they love that they can customize easy Um that they have this predictable upgrades to the monthly releases or if you need them the nightly build to rely on and there's this great community going on and if you want to read a report of that there's a very nice article that's

called the fire doctor story from the sukadora tool and you can find it on the clips foundation website. Okay, so what are the takeaways of today? It's easy to get comfortable with fire. Just try it out. Check if it's something for your use case or not but whether it's a traditional tool or something AI related and it's not as hard as you think because in the end

you saw all the magic all the high level architecture things you already saw in this talk and that's basically it and it's easy to do. There's this equality which we talked about already and last but not least might be important for some of you if you have a commercial offering that you can also if you want to get commercial support for fire. So that's the option and

if you go to the fire website, you can see all the companies which are officially providing support for fire. So then also at your CX just right then after this after the story finishes and there's this buff where we will talk about fire and other things. So hopefully I can see many of you there and yeah some some other talks interesting tomorrow especially the systematic eye coding

which I think will also use fire ID. if you want to hear more of me and my colleague Philip was sitting here. We also have another talk tomorrow then this case AI specific. Okay, that's it. With my talk. Are there any questions? >> Um. The dependency management protocol which is used for the project. Is it NPM? >> Yes. >> It's based on takes the same role that

it's taking Maven for Java, right? >> As I mean, um yeah, there's two things. So, there's the dependencies from from the whole in um environments or the whole vector environment. This is NPM, yes. So, um and that the the code directly within fire, this is all my handle via Inversify. Did I get this correctly or did you ask something? >> Okay, Inversify as far as I understood

This is what I understood. Yes, that inversion of control inversion of control framework it is using the software, right? >> It's it's used in the in the software, >> Is it if we do a parallel with Java, would it be like I don't know Spring or >> Ah. >> But personally I see it like OSGi basically. Um and then you would use Maven Central as the NPM

variant. >> Ah, okay. Yeah. Got it. Okay. The second thing um is a question if you could elaborate a bit about um the you said earlier in the slide that we should prefer um rebinding instead of patching. >> But in my experience with uh Eclipse RCP in the specific with the CDT, every time that there was no door open for extension in any class, I was basically

copy-pasting and doing my version of that class, which is um which is what if I understand it, which is what I would do it also with rebinding, right? I would copy-paste, change, and then rebind to to to replace something that exists. >> Mhm. Exists. >> Yes. So, if you're unlucky and you have something that is not in a class, then you need to maybe copy-paste it or

call it. So, we can go to the to the specific I think was it here? Yes. Oh, sorry. we're mostly using classes for almost everything in in fair. And usually your rebind story really looks like this. You're really just extending a class and then overriding a method. And this really works for 90% of the cases. >> Oh, okay. That means that sorry. You are extending. >> Oh,

okay. Sorry. Well, my my mind was thinking about taking workspace service, changing it, and make my own version of work. And okay, now it makes complete sense. Sorry. I was missing that >> Cuz usually it works like this. Maybe there's some oversight somewhere can happen and people forget for example that make something injectable and then you need to copy it because it was also not exported. Things

like this happen, but then yeah. Just raise it as an issue or contribute yourself an improvement, and this we really want to have the story look like this and not something more complicated. >> Thank you. >> Okay. Any other questions? >> Yes, sir. Um I have not got around to have a closer look at Electron. Could you elaborate a little bit? Is there a node inside it?

>> Uh yes, yes, absolutely. Um I I didn't show it because it's just to simplify, but if you go to the architecture So, basically what you see here, let's go on the back. This same part with an immersive web container you also have an electron process. yeah, it was here a little bit simpler, but it's a very same principle just also an electron. And for the code

generation, for example, there when you when you do your fair extension, you can say, "Okay, this module should be loaded in the front end. This module should be loaded in the back end. And this module should be loaded in an electron." Um so, you can really target there very specifically uh where something of your code should end and others. >> Oh, there's one more question. >> So,

for the communication between front end and back end, you said don't do an extra channel. You have it run through >> Yeah, use as a usually not, yeah. >> So, and then you you you have to have about what workers. >> Do you have like is there a Theia infrastructure for handling workers and background tasks? Or I think there's not nothing specific there. So, we have as

what we do is we use a worker for the plugin host. So, the plugin host is already in a separate Do we have it here? Yeah. It's already This is already a separate process, the Um I don't So, correct me something if I'm wrong, but I don't think there's any specific there. Yes, Thomas. >> You can run the RPC protocol pretty much over any transport. So, if

you have like a a node parent child process channel, you can just do an RPC protocol over that and run your your whatever you Yeah. Absolutely, Thomas is right. So, you can you can reuse them, but I I there's not a specific contribution point to just do it. >> Uh thanks for your talk. Um if I'm a doctor uh with lots of extended services what happens if

I migrate to the next version or to the next >> federal version? Is there a migration path? >> Yeah. Uh it's a good question. Um um So usually, so from our experience that updating you the UFA dependency to a later version is usually not that much Even if it affects parts which you extended. because there's we we don't do that many refactorings or something. So if you

really go through um uh follow for example the community um as a for ex we at one time we for example refactored the menu, so it's a one-time thing to update. But usually even for very large applications it it never takes like more than a day to update. And this is really a already a worst case. so yeah. Uh for specific things for example like this menu

um uh refactoring or this upcoming packaging refactoring with ES build what we do is we have um migration guides. So you can when you look at the change log and there's uh usually the list of breaking changes and there's a small guide if it is um so okay do this and this if you're affected. And for larger things um we have a migration document where we then

suggest okay you need to follow this procedure and then you can can migrate. But yeah, from from experience um um UFA application if you're not updating like 20 versions, so basically almost 2 years. Um but if you're always up to date, this really doesn't take doesn't take long compared to all the rest which you have to do with your >> Okay, and second question, did you provide

something like a S-bomb? If Yeah, there's a S-bomb published. >> Of the of the fair um framework. >> For um reacting on CVEs that are critical is an an issue? >> Um so usually not. So we have we have adopters which will also um have like guidelines that the CVEs uh they don't have they can't have critical CVE um uh CVEs in their application coming in from

fair. So um everything which is usually critical in fair is fixed pretty quickly. >> Okay, thanks. I guess that's it then. Thank you very much for the questions and you're welcome. >> [music]