 Hello, everyone, welcome to Camel4, what to expect. My name is Otave Rodofopisci. I am a Principal Software Engineer at Red Hat. I'm also a committer and a member of the Apache Camel PMC. You can find me online, I'm usually on Twitter, but you also have my mail here should you have any questions after this talk. In real life, I live here in Bernal for eight years already. Unfortunately, I still do not speak fluent Czech, but I keep trying. On the agenda today, I'm going to give a very brief overview of the Apache Camel project. Then I will talk about the motivations and objectives for releasing a new major version of the framework. I would discuss a bit about the changes under the hood, I'll complement my thoughts on how you can plan the upgrades and I'll finish with the questions and answers. The Apache Camel project is basically organized in multiple sub-projects, CamelCore being the largest one of them, it's the one that provides the enterprise integration patterns and components that is what most of the people tend to know about. But then we also have some sub-projects that focus on specific technologies or specific problem domains. We have things like Camel Spring Boot and Camel Quarkus, and we have also things like Camel K, which focus on providing a lightweight runtime for Kubernetes and OpenShift. If you have never seen what Camel wrote, looks like, I'm showing an example here. This one is written in Java, basically shows how you could pick some data from Kafka and send it to a queue on Amazon SQS. This route could be written here in XML or YAML among other languages. With the course of developing Camel 3, we kind of created a few new features and projects that they will become more prevalent with Camel 4. The first one of these projects is Camel J-Bank. Camel J-Bank is basically a way to quickly run the routes you create. You don't have to actually write a full blown Java project to do that. You basically pass a YAML file and Camel J-Bank can run it for you. This makes it a very nice tool for prototyping routes. So whenever you want to try something, Camel J-Bank can help you on that. Camel J-Bank also has features to simplify bootstrapping integration projects for our sub-projects, things like Camel Quarkus. You can quickly export those routes for running on those run times. And lastly, Camel J-Bank also provides functionality on which you can implement new things. For instance, internally, within this project, Camel Caravan, we use Camel J-Bank. Camel Caravan is a toolkit for designing routes. Basically with Camel Caravan, you can use those drag and drop features to select components and patterns and design the integration in a visual way. It basically works as an extension for Visual Studio Code. And Camel Caravan will save the YAML route for you so you don't have to actually write code. And one of the nice things that it has is this arrow button which uses Camel J-Bank to run that integration that you have designed. But I'm here today to talk specifically about Camel 4, what we had in mind when working on this new version of our framework. And when we think about the motivations for working on Camel 4, the one of them, and I think the primary motivation was the release of the Jakarta 10 set of APIs. Camel itself does not use Jakarta APIs, but many of the libraries that we use to implement our components do. So with the goal of being able to upgrade to those libraries, we had this motivation for Camel 4. Then we have another big motivation which is Java 17. The community of engineers working on the Java language has been for many years already developing newer and greater features for the Java language. And we want to be able to make use of those features, both for making our code easier to maintain, but as well as for implementing new features for our community. And then we have a set of projects that are very important for the Java community in general and they are widely used. We have here things like, sorry, Spring Framework 6, Spring Boot 3, and Quarkus 3. Those three projects are widely used around the Java ecosystem, and they too are somehow also motivated in releasing new features based on both Java 17 and Jakarta 10. So it came out as the perfect opportunity for us to work on a new version of Camel 4, aligning with all these five items. When we think about our goals for this release, what we want to achieve, as always for when you are working on a new version of a framework, you always think of the foundations you want to build. And with Camel 4, we again fought on building foundations for the future. So that's why we are aiming at supporting Java 17 as a minimum version. As I said, we want to make use of this great and new features of the Java language, both for our work on the framework as well as for implementing new things for our community. And we see Camel 4 as a forward-looking release. That is, we are already looking forward to the upcoming Java 21 LTS release, which should be, I think, around September. Should be out, I think, around September. And one last point is when we raised this discussion with the community as having Java 17 as a minimum version, we did receive some feedback from the community questioning whether we could support Java 11. But it turns out that since many of the libraries and many of the motivations that we have are already aligned with Java 17 as a minimum, it would be kind of difficult for us to do that. Looking at our work in maintaining Camel and what we did with Camel 3, things that worked well, things that gave us some additional effort, we identified Camel Karath, which is one of our sub-projects, as one of the pain points in our ecosystem. So we decided with Camel 3 to downgrade the effort we have on maintaining this sub-project to as a best effort. In practice, this means that we will decouple the releases of Camel Karath from the releases of Camel Core. So what it means is that when we release a new version of Camel Core, there won't necessarily be a new version of Camel Karath. In the same kind of thoughts, we also took this opportunity to work on goals to reduce our maintenance effort. Camel is kind of a big project. So as always, a new version is a good opportunity to do that. So we focused on doing some internal cleanups as the time goes on and on on a project that is already 17 years old. There's always some technical depth that piles up. So with Camel 4, we did quite a lot of cleanups. I will elaborate a bit more about this in subsequent slides. We also took the opportunity to look at things that within the Java ecosystem, are either being superseded by newer versions or stopped being used. For instance, we know that nowadays, most of the projects are already using JUnit 5. So we decided to drop the support for JUnit 4 in this release. And we also took the opportunity to look at the library of components that we have. Camel has about 300 components, a bit more than that. So when we look at the components that we make available for the community and look at both the technologies and the underlying projects that offer the functionality that we use, we identified about 33 of those that either have become unmounted or were evolving on a pace that was not the same as the rest of the community. And by that I mean, for instance, by this point in time, they still do not support Java 17 or have not yet been supported in Jakarta 10 and so on. Things that would kinda make our release more difficult. And as a result of this evaluation, we had 33 components that were affected. Of those, 20 can be easily replaced by others already available in Camel. And here I'm talking things, for example, CamActive MQ, which you can somewhat easily replace with Camel JMS. And of those components, most of them have shown little usage based on what we could gather from Jira, mailing lists, messages, and chat requests. And one point that is important to highlight here as well is that in some cases, these are temporary. We have, for example, as I mentioned here, CamActive MQ. The community is already working in resurrecting this component based on a newer version that supports Jakarta 10. So it might be that this number of 33 components affected will be reduced as the development of CamO4 progress. Talking a little bit about the changes under the hood, these are things that normally wouldn't matter most for the users, but I think it can provide a good insight about the work that is going on. One of these things is what we call the internal plugin manager. CamO internally has a way to allow the configuration of many things, how exchanges are created, how messages are created, how error handlers are created. And this is done to what we call a plugin interface. In CamO3, this interface was not very uniform. With CamO4, we look at the way we were working with them, and we worked to provide a uniform interface. This is something that does not, again, affect the users, but it turns out that reduces the maintenance effort for us. We also look at things that were somehow public, but shouldn't be, things like introspection support, which is used only internally. And when not talking about code, specifically about the internal code, there are also changes in testing. For instance, we are looking, we are aiming at providing clean builds for Power and S390X architectures. This is Linux on mainframe. Of course, CamO runs fine on these architectures, but we also want the community to be able to build and run the tests on them. Again, on the same topic of reducing the maintenance effort, we re-evaluated how we were doing some of the testing for our components. The way CamO3 used it to do that was through a kind of complex hierarchy of types to set up the CamO context. With CamO4, there is a new JUnit 5-based extension that makes it much easier to set up the context. We basically use the register extension and the JUnit does the bulk of the work for us. Eventually, we hope that this will become something that we encourage the users to do to simplify their part of the testing as well. And lastly, on the part of internal changes, nowadays we know that supply chain attacks has been a big topic, and within this topic of security, many projects are providing the software build of materials. With CamO4, we are going to provide that as well. In this new release, one topic that we focused a lot was on the part of performance improvements. Sometime ago, it became kind of famous, this JDK issue, JDK 818450. Basically, simplifying a lot here, this issue is related to a performance penalty that can happen when you do type checks. If you are working on any application that is performance sensitive, I strongly recommend looking at this material that I'm showing here, especially cracking the scalability wall, which was a talk given at, I think, DevOps UK, where two of the engineers that work a lot on uncovering this issue and working around it talk about the implications of this issue, what was done to solve it, and why Java developers should care about it. As we work to work around this issue and fix the problems that we identified as part of that, we optimized several components on CamO, notably SIDA and disruptor. We have, of course, some changes also happening on Core, which benefit basically all the 300 components that we have. And of course, as during the course of investigating these performance issues and working to correct them, we came out with other micro optimizations that alone wouldn't do much changes, but can provide some nice performance improvements. And to showcase a little bit about what I'm talking about in terms of performance improvements, I'm going to show a few examples. For instance, on the case of SIDA, which is a component that is kind of widely used, in a scenario with low contention, we have 19% faster throughput with CamO 4. On a scenario with four consumers and one producer, 18% faster, with a little bit more contention, eight consumers and one producer, 51% faster, and so on. Also, disruptor is another component that is also used, especially in scenarios where you have multiple producers. On the case of disruptor, we have 36% faster results with CamO 4. And so on. Overall, what we found out is that CamO 4, in our tests, it was 80% faster, 80% of the times for the SIDA component when compared with CamO 3.20.4. For the disruptor component, when compared with 3.18.6, CamO 4 was faster, 80.6% of the time. And comparing with 3.20, CamO 4 was faster, 91.9% of the time. If you're interested in learning a little bit more about the performance improvements that we worked on CamO 4, I suggest looking at this blog post where we discussed a little bit more about the changes that we did, what we found out, some of the metrics that we gather, and more. I hope that by this time, I kind of sold you the idea of CamO 4, and I hope you are all excited about upgrading to this new version. It is not, the final version is not out yet, but we already are working on a release candidate. We have a few milestones available already. But what should you expect of a migration from CamO 3 to CamO 4? Well, first of all, the migration from CamO 3 to CamO 4 should be much easier than was from CamO 2 to CamO 3. We are aiming for a drop in replacement. Additionally, you should not expect any kind of DSLs incompatibilities. CamO has, I think, quite good track record of retaining this backwards compatibility, and it should not be different this time. With regards to the planning, one thing that might change a little bit is what kind of packaging of CamO you are using. If you are using a downstream or a commercial distribution, do talk to a vendor. They may have their plans already. If you are using the upstream version, the open source one from Apache, the usual recommendations for any upgrade matter here. Save time for testing. We do our best to ensure that CamO has a good testing coverage, but there's only so much we can cover. Do plan to provide feedback to the community. If you try the upgrade, something's not working, do share that with us. Do open tickets. Go to our mailing list or chats and provide the feedback to us. And share the knowledge with the rest of the community. The problems that you face today might help someone else going through the same problem in the future. It also helps us as a community to learn from the problems that the community is having, and with time as we work on other versions, other features, we can learn from that. The path for upgrading, sorry, the path to CamO 4 might depend where exactly you are. During the course of developing CamO 3, there were a few important milestones in terms of what we achieved. For instance, the first version where we officially supported Java 17, the last version where we supported Java 8, and so on. So things like this might matter as well on your upgrade plans. In general, as I said, migrating from CamO 3 should be relatively easy, especially if you're using maintained technologies. If you have some component that's not gonna be removed or have been temporarily removed, that should be a good sign as well. If you're using one of the modern projects that we have, CamO Spring Boot, CamO Quarkus, CamO K, migration should be fairly simple. If you're using the plain CamO Core, a good sign is if you're using a relatively newer version of CamO 3, especially a relatively newer LTS version. A bit more effort might be required if you are using an older LTS version, especially older than 3.14. Not because we broke features or because some incompatibility along the way, but because of the cost of many small changes aggregated all over the time. And some code changes definitely will be required if you are using those internal APIs that I mentioned that were changed. I don't think, I think many in the community are not using those APIs, but if for any reason you are, then do prepare for some code changes. Those changes also should not be so complex, but of course is something that will eventually change. If you are using OSGI, as I said on the beginning of this talk, we are downgrading our efforts on CamoCraft to a best effort, so ideally you should plan to move your OSGI workloads to CamoQuarkus, CamoSpringBoot, CamoK, CamoCafkaConnector, any other project that might suit your needs. User impacting changes, which should not be widely impactful are, in terms of logging, with Camo4 we upgraded SLF for JPI to version 2.x. This version brings a few different dependencies, so depending on what you use as a login, you might need to adjust a little bit the dependencies that you use. One of the exchange patterns that we had and was not widely used, called inoptional out, was removed. And for those using the CamoMain and using a main listener to configure the CamoMain, one of the methods that was used to perform that configuration, the method of configure was removed. It was already deprecated on Camo3, and with Camo4, this method is not available anymore. For those users, they should move to either the after-configure or the before-configure methods. If you are still on Camo2, then that migration path is a little bit more problematic. First, Camo3 was modularized, so the dependencies that Camo2 provided are different than the ones provided by Camo3. So migrating from Camo2 involves adjusting those dependencies and package changes and so on. There were also changes in terms of handling multiple and single contacts, and Camo3 also brought a Java 11 as a minimum version. So it's quite a lot more work than the migration from Camo3. Closing this talk about Camo4, I leave these comments that even though Camo4 is not out yet in terms of there's no fully stable version, we already have several milestones available. Our release candidate is planned for just a few weeks in the future, so do start planning now. Do plan to adjust your applications, see how they work with Camo4 and provide the feedback to the community. Avoid the unmanned versions. We still have many users on the community, either using very old LTS versions of Camo3 or even using Camo2 completely, so please do plan to upgrade those. We are not maintaining those and the community is not receiving fixes for CVEs and bug fixes at all. We evaluate usage of old technologies and standards. If you are integrating with some tool that has become unmountained, that's something you should look at your architecture and see what you can do to move away from that because if there's a good chance that the component user to integrate with that might not be available in the future. And as I mentioned earlier, please share the knowledge. It helps the whole community. It helps us to learn what we did well, what where we failed and we learn to do better in the next version. And with that, I think we are open for questions and answers if there's any. Yes, so the question is, what about the Camo Kafka connector if it's planned for Camo4? And the answer is yes. It's planned for Camo4. We, he worked at the Camo Kafka connector on the course of the development of Camo3 so that it uses Camelets. And as we progress with development of Camo4, we will certainly work on a new version of Camo Kafka connector that makes use of Camo4 Engine and the new Camo Camelets that will become available. Welcome. Any other question? So thank you everyone.