JavaZone 2025: A Speaker’s Perspective

I usually write about quantum computing, sometimes about Java and related things. However, fresh from my recent experience as a speaker on one of the largest European conferences (and one that’s marked as one of the best), I thought that you, dear Readers, may be interested in a slightly different article. This time I write about how it was to be one of the one hundred speakers on JavaZone 2025. I thought you may find it interesting to learn how to secure a spot at such a big event, prepare, and give it a go.

Let’s begin with some key facts. JavaZone 2025 took place 2nd-4th September 2025 in Lillestrøm, Norway. According to this database, it hosted 90 speakers, 150 exhibitors, and 2500 thousand attendees. It definitely felt crowded there, especially in the partners’ area. The first day actually took place in Oslo, and hosted exclusively workshops. The main two conference days, with presentations and lightning talks, were 3rd-4th September. There was one special event the day before: a dinner for the speakers. I couldn’t attend it due to personal reasons, but I quite regret it. It’d be a great opportunity to hang out with the others, since I didn’t actually have a chance during the conference days. 

I gave a lightning talk titled “Quantum Leap with Java: An Unrealistic Dream?” You can find it recorded here. Be sure to watch at least a minute or two of it, since there’s one important thing I write about later. I think it was well received, though I didn’t get that much feedback, to be honest. Anyway, I’m quite happy with how I performed. And speaking of which, how did it actually go?

Getting a Spot

Nothing of this would’ve happened of course if I didn’t get a spot in the first place. It all started on 18th February, when I got an email that a call for proposals was opened. This email isn’t sent to everyone, but if you’ve ever submitted, then you’ll get it unless you’ve unsubscribed yourself. This time it was actually my second time trying to get my talk accepted. Two years ago, in 2023 I submitted a longer form, a 45-minutes presentation about the modulith architecture and different libraries supporting it. It was rejected, but gave me quite a precious lesson on how to make a second attempt. For various reasons I couldn’t try last year, so I waited until 2025. The call for proposals ended 28th April, and on 25th June I knew mine was accepted. How did I secure it this time?

First of all, I realised that the modulith pattern might have been too weird to be accepted. After all, there’re many Java developers that have very bad memories when the word monolith is spoken aloud (me included). And though I believe that the modulith architecture is one of the best ever proposed (and quite different from the real monolith), it hasn’t actually gained any momentum until this year. Instead, I opted for something “sexier”. Quantum computing is definitely quite famous despite still being a niche thing. I started to learn it a year before submitting, so I was already well prepared to talk about it. Moreover, I’ve always been deeply concerned that Java developers are missing yet another opportunity to develop one of the great technologies of this decade (the second one being AI), so I thought it’s a great opportunity to hit two birds with one stone. 

Second of all, a shorter form is easier to “squeeze in” in case your topic isn’t among the top contenders, but is still solid. Therefore I opted for a lightning talk instead of a presentation. Moreover, it suited my purpose better. Java libraries for quantum development are somewhat disappointing, and I didn’t see a big point in presenting what other languages are capable of at a conference having the word “Java” in its name. However, one of the purposes of lightning talks is to spread ideas, and in my case – alert our Java community. It’s beyond my competence to decide what we should do with the fact that Java is heavily lagging behind in the quantum race, but I felt obligated to shout it out anyway. Hence the choice of the form of lightning talk, which I believe worked quite well.

Once I’d made up my mind, it was time to apply. You have to fill a pretty long form in order to submit your talk. There you must provide a title for your speech and a publicly visible, short description. This is the abstract that ends up in the program eventually. There’s also a separate, longer program-committee-visible description. It’s to help its members evaluate your proposal. There you must provide a more detailed layout. I did it in the form of a list of bullet points, but there’s no style enforced whatsoever. You also have to specify the form of the “thing” (a presentation, a lightning talk or a workshop), duration, and language. I opted for English for two reasons. I speak it way better than Norwegian, and it made more sense given it’s an international conference. Finally, you must provide information about yourself, including a short bio, links to your online presence, and conference availability. For example, if you aren’t fully flexible, you can state it there. 

There’s one caveat filling the form though. Sometimes it doesn’t get saved. So it’s safer to write the stuff down in some notepad, and then just paste and send, which is what I did.

Preparing the Talk

Regardless of what subject you have chosen, there’s one thing you must remember about above anything else: time. Every form of presentation is timeboxed, and the technical crew is pretty strict about staying within this limit. It means that you have to take extra care about the amount of material you want to show.

My rule of thumb is to prepare the stuff for only 75% of the available time. This gives me some safety margin in case I talk a bit too long about something or improvise an anecdote or two. I guess it happens to all speakers, especially when nerves and adrenaline kick in. Having those extra minutes can be a lifesaver. In the case of my talk, I planned to prepare the material for 15 minutes, and have 5 minutes just in case. The actual talk took me slightly longer than 18 minutes, so it worked pretty well.

The starting point for my preparation was the layout of the talk that I submitted a couple of months before. Don’t worry, it isn’t carved in stone. Speakers are allowed to modify their submissions, to some degree of freedom obviously. I’ve never done this, so I don’t have first-hand experience on how it goes.

Regardless of whether I prepare public talks, or courses, I always write down what I want to say. Exactly the way I’ll be saying it. This way is much easier for me to prepare for the actual event. It reduces the variability when repeating the talk during preparation, and helps me memorise the key points. When this is done, I do the slides too (or any other form of presentation, ex. code). With the whole “presentation pack” in place, I read it out loud trying to simulate actually giving it as much as possible with a stopwatch. The goal is to make it within the 75% of maximum time available. If I can’t make it most of the time, it means I’ve prepared too much material and have to edit it.

If I’m happy however with the way this part goes, then I use a highlighter to mark all the important keywords and parts of the talk. It’ll be crucial during the repetition phase, which is next. During it I read the talk aloud. I haven’t counted how many times I did it, but the point wasn’t to learn it by heart. It was on the other hand to memorise it enough to be able to give it smoothly even when I’m stressed or something unplanned happens.

Once I’m happy with it, I practise giving it the way I actually want to give the talk. With slides, code, and everything else. This helps me automate moments of switching the slides or live coding. Again, it’s to mitigate the stress ruining your talk. Why is it so important? I’m a pretty cool person, but still I always get a bit nervous when I talk during such events. I’m fairly certain that most of you have that too. Even if it isn’t a full blown stage fright, it may still ruin your talk. So I prefer not to take chances and just prepare well enough.

Finally, I “give” the speech with the stopwatch again. It’s just to double-check if I still make it in time after all this practice. If so, I take a couple of days just before the conference free from the talk, to let it sink in my head, and rest a bit. And last but not least, taking a good night’s sleep the night before the talk is crucial.

The Conference Day

The conference day is no less important than all the preparation before. I always make sure that the means of transport I take can take me well before the time of my talk. I wasn’t at the opening session on JavaZone, but still made it therebefore 10 o’clock. It was much earlier than my talk, that was a bit after 4 o’clock, but I wanted to attend some presentations, and hang out with friends. These are actually two traps that one can easily fall into.

Attending the presentations can be quite mentally exhausting. I always try to avoid participating in too many if I’m the speaker, so this time I also chose three I was the most interested in, and skipped the rest. You may be thinking that I was too harsh on myself, and could’ve attended more. However, it’s important to remember that the attendees are at the conference to take the most of the talks that’s possible. It’s a matter of professional ethic to be able to be at your tops when you’re giving a talk. That’s why I do my best to avoid cognitive overload, and that’s why I went to only the talks that I really wanted to attend.

One of the talks that I attended was in the room that mine was scheduled for later that day. JavaZone actually hosts a special walk around the day before the first day of the conference. It’s meant for the speakers to get familiar with the rooms and facilities. Unfortunately, I couldn’t attend it, so I had to rely on that little trick to know what the room looks like. I didn’t want to discover something surprising just before my talk.

The second trap is networking or hanging out with friends. Not because it can be tiresome. Usually it isn’t. However, talking for a couple of hours puts a huge strain on your throat. So while I really enjoyed time with them, I made sure that I have at least one hour of keeping my mouth shut, so the throat can rest. 

What Went Well and What Went Wrong

Well, I got the spot. But more seriously, I believe that the choice of the form (lightning talk), and a “sexy” topic (at least I believe quantum computing can be considered one) contributed to getting my proposal accepted. I’ve learned that there were around 800 submissions, so only approximately one in eight got accepted. I’m not sure I wouldn’t fail to get a place again if I didn’t do it this time with a better strategy.

I’m also quite happy with the amount of preparation I put into the talk. It went pretty well despite I caught some nerves in the middle of talking (of course!). I’m fairly certain that if I hadn’t memorised it so well, I could’ve panicked or at least not given it so smoothly.

According to my estimation (which can be wildly wrong since I did it just on the stage, two minutes before the talk), there were about 20-30 people in the audience. Given the relatively late time, I think the talk was still fairly popular. I may as well be deluding myself, but I’m anyway satisfied with this.

And last but not least, I actually got some feedback and follow-up questions. The feedback was generally positive, though I also got some remarks about stuff I should work on if I’m to give yet another talk. It’s actually quite valuable, I like to take every chance to improve my skills. Plus, it showed me that there were at least a couple of people that were genuinely interested in the talk.

That would be it when it comes to the positive things. And now to the downsides. First of all, despite being wary of not showing too early, and conserving my energy, I failed to do this. I really wanted to hang out with friends, and attend some talks, but in turn it made me more tired than I wished. It wasn’t good from the talk’s perspective, so I definitely should’ve worked a bit on balancing this one out. But on the other hand, it’s hard to just turn your folk down, so I may as well repeat the same thing again.

That would be more on perfecting my performance. But there was something that I really screwed up, and didn’t realise until it was way too late. I have eye comfort settings turned on on my devices almost all the time. The lights in the rooms at Nova in Lillestrøm were quite warm, so I haven’t turned it off. After connecting I check if the presenters screen is in neutral color, which was. This was to ensure that the presentation will also be displayed without any filter on. But I didn’t think that the software they used for recording my presentation would also pick up the warm colour that the eye comfort shield bathed my display with. When you look at the slides in the Vimeo recording, you’ll see that they have an unnaturally warm tone. I haven’t confirmed it with JavaZone organisers, but I’m fairly certain that it’s because of my settings. Next time I do have to remember to turn this off no matter what to avoid peach vibes emanating from the slides.

Conclusion 

It was really a great experience to give a lightning talk at this year’s JavaZone. I really enjoyed it, and I hope my audience did too. I wouldn’t be there, if not for the carefully prepared strategy for picking up the topic and the form of presentation. I also spend a lot of time preparing for it, so I can give it as professionally as possible regardless of conditions or my psychological state. The most important thing was to be mindful of the time limit at every stage of preparations, but proper repetition did its job too.

The talk went quite well, and I’ve got enough positive feedback to call it a success. Despite overestimating my stamina, I avoided most of the pitfalls of all the things that surrendered my talk. However, one can never be overprepared. My eye comfort settings badly affected the way the slides were recorded, effectively downgrading the experience of anyone watching my talk on Vimeo. This is something to work on in the future.

Finally, this isn’t meant to be a guide on how to be a speaker at JavaZone (or any bigger conference as a matter of fact). However, if you find this article useful in your preparations, I couldn’t be happier.