A Preview of What's Coming in Project Leyden - Inside Java Newscast #78

[@Adyel-YT]

One important tip for graphs: Always start the axes at 0. Starting from a higher value, like 2250, distorts the visual scale, making minor differences look exaggerated. It misleads viewers about the real impact and skews the data’s true story. For clarity and honesty, always use 0 as the baseline. It's especially true for comparison data, benchmark or otherwise.

[@billykorando]

I see you point, I don't know if I particularly agree. I'm doing an internal comparison, and not comparing across competing products (i.e. here is why Java is "better" than [insert competing language/platform], or an Oracle offering is "better" than [insert Oracle competitor]). Within that context no application like the Spring Boot Petclinic application will start anywhere near 0 milliseconds, or for that matter complete 0 requests over a 10 second period. So including those as starting points would leave a graph with a lot of white space and thus difficult to read. If I wanted to be "deceptive" about the benefits of Leyden, I could had simply removed outliers, or created a demo that's non-representative of real world applications, but that plays well to Leyden's advantages. (granted in some ways the Petclinic application does that, but then I also explain in the video applications that would benefit more from Leyden)

[@Adyel-YT]

@@billykorando Oh, my previous comment wasn't directed at you! I was just making a general point about graphs. English isn't my first language, so I may have chosen the wrong word. I think using "honest/misleads" came off too harsh, and it sounded like I was criticizing you, which wasn't my intention. Graphs can be interpreted differently depending on how the data is presented, especially when compared to surrounding data points. For instance, if the baseline is removed, the graph might lose some of its impact. In your graph, I couldn't get much information about the percentage change. If you had included the time from zero, I could have better interpreted the reduction-maybe around 20-30% overall. Without that, it's hard to tell. This is important to me because if the impact is only 0.001%, it might not be as relevant to me. I hope this helps explain my perspective. There's a great book called "How to Lie with Statistics" that gives more examples of what I mean. There's also a TedEd video titled "How to Spot a Misleading Graph by Lea Gaslowitz" - a very short video that will give you the gist of what I intended to mean. Finally, thank you for all the hard work. I really appreciate everything you guys do. I'm sorry if I was rude.

[@billykorando]

@@Adyel-YT Gotcha, sorry if I came across as a bit defensive. You're absolutely right that you can easily lie/mislead with doing performance comparisons. At least for my part, I wouldn't do comparative performance across some sort competitive boundary* (like in the examples I gave in my previous reply), because even outside of how you show the graphs, it's very easy to be deceptive. Such as designing a test case that plays to the strengths of what you are showing, or even unintentionally by not being familiar with the competing offering and not using it in an optimal way. I could had done a bit better with the graph I showed. I'm not deeply familiar with performance testing, nor visualizing it. So it took me awhile to even get to the point where the result of my (simple) testing was somewhat visualizable. * In full disclosure I have done this before, but came to a self-realization that I should avoid such a practice in the future

[@Adyel-YT]

@@billykorando Thank you for being understanding and kind 😊😊😊

[@Nick-yd3rc]

Can’t resist looking the whole time at the cat stand on the left in the hope for a 🐈 or a 🐈‍⬛ to jump into the view. Would become the next Java superstar.

[@billykorando]

Hah, you might see Vicky and Lulu in that tree pretty soon. It's starting to get colder, and my office is higher up so stays warmer.

[@Nick-yd3rc]

So from the ops point of view, how much extra space should one reserve for a file system volume resource when deploying with that feature? And should this become part of the deployment workflow now? You’d now configure your deployment pipeline to run several load tests ahead of the first production startup? I mean we run load tests but only as a part of the CI pipeline, when the staging is done, we don’t touch the resulting vetted artifact. But here it seems to make an extra step necessary for producing the cache. Any guidance on that would be welcome!

[@billykorando]

Regarding the amount of disk space to set aside for the cache, that’s very much up in the air right now. The caches are somewhat large. From memory, I believe it was over 100MB, however when talking with the Leyden team, reducing cache size is a goal, just not a goal right now as they first focus on the startup and time to peak performance goals. As for the cache, you only need to include the VM argument in your CI builds, and the cache will be generated on JVM shutdown… and the VM argument will be the same between your CI build and production environment. So you won’t need to maintain two different java commands. Though the VM argument I showed, will be changing in the future to AOTCache (I believe, something similar to that).

[@gudenau]

I have some interesting projects that I want to do with this, I ought to experiment with this some. I really do dislike using mailing lists.

[@mpenet]

> Over the summer of 2025 Leyden started releasing early access (EA) builds You probably meant 2024

[@ammbra1508]

Fixed

[@ebuzertahakanat]

Hi Billy, Can you please tell the big boss that we want the JAOTC back?

[@Nick-yd3rc]

AOT isn’t news and there’s some prior experience gathered in several communities. Is there any sort of comparison survey covering some production grade implementation, such as .NET AOT?

[@heyyrudyy404]

AOT cache are the future seed 🌱 of Java Packages 📦, because it will enable with a good API to communicate with a Build Server Protocol, Idempotent and Incremental build on top of Idempotent and Incremental compilation.

[@smurfandturfer]

BSP mentioned

[@mikep2262]

Jumping thru so many hoops to avoid traditional compilation. Is the complexity of Java worth it...? Or, simple use Rust or Go.

[@PterAntlo]

The difference is that you can decide how much traditional compilation and how much JIT you want for each of your projects individually. Meaning you can always start with the easiest path (all JIT) and then move to increasingly more compilation if that's useful for you. It is the best of both worlds and the only downside is that you have to do a bit manual work for the increased power. Also, it can be used by frameworks as a baseline instead of everyone building their own thing.

[@LA-fb9bf]

​@@PterAntlo Java has a huge and well founded ecosystem. Switching to another language ist not a real option!

[@javierflores09]

I mean, you won't get the performance that Java gives you with these languages by default, you'd have to go the autoFDO/PGO route and that is still wildly unknown territory as far I'm aware. For simple enough programs, that may not be the case but Java is used for pretty big software that benefits from the fact that it has a very competent JIT as well as an amazing set of garbage collectors

[@tintifax8531]

The complexity of Java? Sure, I'll switch to the refreshing simplicity of Rust in a heartbeat.

[@thomaswuerthinger992]

For a direct compilation of Java programs to machine code without a training run, there is also the option to use GraalVM native image available.