Foojay.io, the website for the Friends of OpenJDK, is turning six years old. To celebrate, Frank Delporte headed to JCON in Cologne, Germany, and sat down with twelve members of the Java community to talk about what Foojay means to them, what they learn from each other, and how the community is evolving.

This episode covers a lot of ground. Sharat Chandar reflects on 25 years in the Java community and why the people are what keep the language alive. Markus Westergren and Iryna Dohndorf both focus on a theme that comes up again and again: developer sustainability. Not just green software, but how you stay healthy, grounded, and relevant when AI is changing everything around you. Markus and his wife researched how developers are reacting to AI, from ignoring it completely to transforming everything they do. Iryna talks about building resilience and robustness as skills, not afterthoughts.

René Schwietzke dives deep into JIT compilation and his work on the 1 billion row challenge, writing fast pure Java code without reaching for unsafe methods. Gerrit Grunwald explains the Disco API, the tool behind SDKMAN, Gradle, and more, which tracks every OpenJDK distribution available, including ones you have probably never heard of from Asia. Catherine Edelveis walks through why choosing the right OpenJDK distribution matters and how reducing Docker image sizes improves both security and performance. Jago de Vreede built a JavaFX UI for SDKMAN and talks about what he keeps learning from the community.

Annelore Egger mentors people who think they do not know enough to speak at conferences. Spoiler: they do. Buhake Sindi brings Jakarta EE into the AI agent world with LangChain4J CDI and a talk on agent-to-agent protocols. François Martin just published a fresh Foojay article on flaky tests and shares what writing and mentoring have taught him about open source. Dominika Tasarz-Sochacka, Frank's new Foojay colleague, shares her vision for growing the community and making it even more welcoming. And Geertjan Wielenga, who started Foojay six years ago, joins remotely from under a lighthouse in Ireland to look back and look forward.

Foojay is more than a blog. It is a Mastodon server, a Slack community, the Disco API, a book on sustainability, a podcast, and now an education catalog. Six years in, it is still growing, still community-driven, and still very much a place where anyone who works with Java is welcome.

YouTube

Podcast Apps

You can listen and subscribe to the Foojay Podcast on:

• Spotify
• Apple Podcasts
• And most others...

Content

00:00 Introduction

02:16 Sharat Chandar

• https://www.linkedin.com/in/sharatchander/
• Java community and history
• What you can learn from conferences and articles

05:37 Markus Westergren

• https://www.linkedin.com/in/markuswestergren/
• https://foojay.io/sustainability-for-java-developers/
• https://foojay.io/today/join-slack-com-t-foojay-signup/
• Book "Sustainability for Java Developers"
• How to "sustain yourself" in this strange-AI-changing-world
• Everyone in the Java community is approachable and wants to help you

09:46 Iryna Dohndorf

• https://www.linkedin.com/in/iryna-dohndorf/
• https://foojay.io/today/author/iryna-dohndorf/
• Mentoring about sustainability as a developer + groundness + robustness skills
• High performance without crushing your soul

13:59 René Schwietzke

• https://www.linkedin.com/in/reneschwietzke/
• https://foojay.io/today/the-curious-case-of-different-runtimes-with-different-training-data-jit/
• Diving deep into the runtime, JITWatch
• About the broad mix of topics handled on Foojay
• Foojay helps connect the Java community with Mastodon
• Writing the best performing pure, safe Java code for the 1B row challenge

18:28 Gerrit Grunwald

• https://www.linkedin.com/in/gerritgrunwald/
• https://foojay.io/today/author/gerrit-grunwald/
• https://foojay.io/today/disco-api-helping-you-to-find-any-openjdk-distribution/
• https://sdkman.io/
• The Disco API, the source with all the available OpenJDK distributions, is used by SDKMAN, Gradle, and many other tools
• About the many distributions that are available, even ones that are mainly (and only) used in Asia
• About bringing opensource projects to Commonhaus to ensure their future

27:45 Catherine Edelveis

• https://foojay.io/today/author/catherine-edelveis/
• https://www.youtube.com/watch?v=Ytdo8OGEYFI
• https://foojay.io/today/which-java-runtime-should-you-use-in-production-comparing-openjdk-distributions/
• Reducing Docker sizes improves security and performance
• Many distributors provide builds of OpenJDK

31:16 Jago de Vreede

• https://foojay.io/today/author/jago-de-vreede/
• About the Java community and the place of Foojay in it. What is good, what are we missing?
• SDKMAN, creating an UI for it, and using the many OpenJDK distributions

35:05 Annelore Egger

• https://www.linkedin.com/in/anneloredev/
• https://foojay.io/?s=egger
• Java community, conference volunteering, mentoring
• How to become a conference speaker
• Learn by teaching

38:03 Buhake Sindi

• https://www.linkedin.com/in/buhake-sindi/
• https://foojay.io/today/author/buhake-sindi/
• https://github.com/langchain4j/langchain4j-cdi
• Jakarta EE, LangChain4J CDI, Agent to Agent
• Impact of AI on developer life and sustainability
• Get in touch with your "Java Rockstars"!

44:03 François Martin

• https://www.linkedin.com/in/fran%C3%A7oismartin/
• https://foojay.io/today/author/francois-martin/
• https://foojay.io/today/eliminating-flaky-tests-to-end-world-hunger/
• https://foojay.io/today/five-ways-to-use-gradle-enterprise-to-identify-and-manage-flaky-tests/
• Learn from mentoring, for example, how to earn from opensource
• Foojay author, just published an article about Flaky tests
• Learn from writing and reading

48:18 Dominika Tasarz-Sochacka

• https://www.linkedin.com/in/dominikatasarz/
• https://foojay.io/today/author/dominika-tasarz/
• https://foojay.io/today/join-slack-com-t-foojay-signup/
• https://foojay.io/today/how-to-submit-your-next-article-on-foojay-io/
• The future of Foojay, how can we get the community even more involved
• What you can learn from the community

51:18 Geertjan Wielenga

• https://www.linkedin.com/in/geertjanwielenga/
• https://education.foojay.social/
• Java communities are everywhere
• How Foojay started and grew
• How can contributing to the community influence your career
• Can Foojay connect to universities and other educational initiatives

58:15 Conclusion

The post Foojay Podcast #94: More Than a Blog: How Foojay Connects, Sustains, and Evolves the Java Community appeared first on foojay.

Rita Mae Brown once said:

Insanity is doing the same thing over and over again and expecting different results.​

However, everyone has at least once experienced a test that failed and then passed in the next run without changing the code or the environment. In software engineering, we don't call it insanity; we call such unpredictable failures flaky tests. At first, they may seem like minor problems, but like clutter in a junk drawer, they become worse over time if you never take care of them.

What if we lived in a world where we could solve massive global problems like world hunger by eliminating flaky tests in software development? While it may seem exaggerated, it is closer to the truth than you might think, and it highlights the enormous cost and resources that flaky tests drain in development teams worldwide.

Why Do Flaky Tests Matter?

1. Waste of Time and Money: When a test fails, it can be difficult to tell at first glance if there is a real bug or if the test is just flaky. Developers often have to rerun tests, sift through logs, and add extra debugging code to confirm the issue is genuine. Over time, these continued efforts add up to an enormous cost. Brian Demers and I estimated in our talk "Testing on Thin Ice: Chipping Away at Test Unpredictability" that $36 billion are wasted every year due to flaky tests worldwide—shockingly close to the $40 billion it would take to end world hunger by 2030.

2. Erosion of Trust: When more test failures are due to flakiness than actual issues in the code, the team loses confidence in the test suite. As a result, teams start to ignore test failures in general, which means that genuine test failures also get ignored. This means that bugs can slip through to production and cause more severe and expensive problems in the future.

3. Slowed Development Process: Flaky tests can slow down the CI pipeline, especially when developers must rerun it multiple times to get it to pass. In one project, our test suite took about an hour per run, but because of the flaky tests, we had to rerun it at least four or five times per merge request. The worst thing is that when someone else merged new code to the main branch, we had to rebase and try getting the pipeline to pass again. In practice, we would spend most of the day watching the pipeline to get a single change merged.

Like a junk drawer that becomes more daunting with each new item you toss in, allowing flaky tests to accumulate makes it more likely that you'll put off fixing them.

Common Causes of Flaky Tests

To effectively address flaky tests, you have to understand why tests become flaky in the first place. The most common reasons include:

1. Timing Issues or Hard-Coded Delays:
   Using fixed waits, like Thread.sleep(500) instead of waiting for conditions to be met, will lead to unpredictable failures. The test may pass or fail if the system is faster or slower than expected.

2. UI Race Conditions:
   In essence, this is another timing issue. The test may fail if you interact with a UI element in an end-to-end test before it is fully loaded. When you have hard-coded delays or do not wait, you will likely run into this issue on slower runs.

3. Unreliable or Shared Test Data:
   Using the same data across multiple tests can make tests unreliable. For instance, creating a user with a fixed username in one test causes another test to fail when trying to create the same user. Randomly generated data may pass the first time but fail the second time if it violates a validation rule. For example, if a form field restricts the maximum length to 20 characters, the test succeeds if the first randomly generated string is 8 characters long. However, the test will fail if the next run generates a text with 22 characters.

4. Unstable Environments:
   Tests that rely on external services or shared resources can break if the services are slow, unavailable, or unreliable. This is especially problematic in CI environments, where the resource allocation is usually constrained and can differ from one run to the next.

5. Test Order Dependencies:
   If one test relies on the state left behind by another test, parallel or out-of-order execution can lead to failures. Each test should be able to run independently.

Strategies to Keep Tests Reliable

1. Awareness of Flaky Tests

You can't eliminate flaky tests if you don't know they exist. Every time you come across one, ensure you mark it using a consistent comment like:

// Flaky Test
@Test
void testSomething() {
    //...
}

Encourage everyone on the team to do this. The consistent keyword makes it easy to find all flaky tests in the code and gives you a quick overview of how many you have and where they are located.

2. Fix One Flaky Test Each Sprint

Adopt the following rule for your team: For each sprint, fix at least one flaky test before starting a new task or feature.

Think of it as putting away one item from your junk drawer each week. Over time, the drawer (your flaky test backlog) will be empty. This practice is easy to justify to management ("it's just one test per sprint") but makes a considerable difference cumulatively.

Some teams go further by dedicating a day (like "Flaky Test Fridays") to address these issues systematically. This can be especially effective if your project has many flaky tests.

3. Use New Test Data

Make sure each test starts with a clean slate:

• Isolate Test Data: To prevent collisions, use unique data for each test. Tools like Testcontainers allow you to spin up disposable containers for databases and other services quickly.
• Setup and Teardown: In frameworks like JUnit, use @BeforeEach to set up fresh data and @AfterEach to remove it:

@BeforeEach
void setUpData() {
    // Insert test data or start a container
}

@AfterEach
void cleanUpData() {
    // Remove test data or stop the container
}

4. Wait for Conditions to Be Met

Avoid hard-coded delays by waiting for specific events or conditions. For various popular end-to-end testing frameworks:

Selenium: Use WebDriverWait to wait until an element is present or clickable:

WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement element = wait.until(ExpectedConditions.elementToBeClickable(By.cssSelector("[data-testid='submit-button']")));

Cypress: Utilize built-in commands like .should('be.visible') to wait for elements.

Playwright: Use Playwright's auto-retrying assertions, like toHaveText and toBeVisible. They wait for conditions to be satisfied and will fail if not met within a certain time (timeout). For example, when you click a button and expect an element's text to change:

// ❌ Flaky: checks the text immediately; may fail if the text hasn't updated yet
expect(await this.textarea.textContent()).toBe('expected text');

// ✅ Reliable: waits until the element has the expected text
await expect(this.textarea).toHaveText('expected text');

WebdriverIO: Similar to Playwright, built-in assertions automatically wait for conditions to be met within a configurable timeout:

// ❌ Flaky: immediately checks if the button is displayed; fails if it isn't ready
expect(await $('[data-testid="submit-button"]').isDisplayed()).toBe(true);

// ✅ Reliable: waits until the button is displayed
await expect($('[data-testid="submit-button"]')).toBeDisplayed();

This approach makes tests more resilient to variations in system performance and load.

5. Run Tests in Parallel

Parallel execution speeds up testing and uncovers hidden dependencies:

• Gradle: Enable parallel execution of test tasks with the --parallel flag.
• JUnit 5: Set junit.jupiter.execution.parallel.enabled to true to run tests in parallel.
• WebdriverIO and Playwright: They run tests in parallel with different files by default. You can also configure Playwright to parallelize tests within a file.

If tests fail when run in parallel, they may be relying on a shared state.

6. Temporarily Quarantine Flaky Tests

When a flaky test that is not part of your change fails and blocks progress, quarantine it so it doesn't prevent you from merging:

// JUnit
@Disabled("quarantine: reason or link to issue here")
@Test
void flakyTest() {
  //...
}

// Jest
// quarantine: reason or link to issue here
it.skip('should throw an error', () => {
  expect(response).toThrowError(expected_error);
});

Use a consistent prefix (e.g., quarantine:) to easily find and track these tests. However, do not let quarantined tests remain ignored forever—make fixing them a priority.

7. Split Up End-to-End and Integration Tests

End-to-end and integration tests are often slower and more prone to flakiness because they involve multiple components. Evaluate whether each test is at the right level of abstraction:

• Integration Tests: Verify how your component behaves when interacting with other components (e.g., between your code and a database) without using the UI.
• Unit Tests: Verify the behavior of individual functions or classes in isolation.

Teams often default to adding new integration tests because it seems more straightforward: fewer, broader tests can cover more code. However, this approach leads to larger, slower test suites that are harder to maintain. One practical approach to address this issue is to refactor complex, multi-purpose methods so each method has a specific purpose. This simplifies methods and makes them easier to test with unit tests. For instance, in one project, I took a monolithic integration test suite that ran for five minutes and restructured it so that most logic was covered by unit tests instead. This ended up reducing the total runtime to just 11 seconds.

Building a Reliable Test Suite: A Cultural Shift

Eliminating flaky tests isn't just a technical challenge. It requires a cultural shift within your team:

• Educate the Team: Explain the impact and costs of flaky tests. Share examples and encourage everyone to treat flaky tests as a priority.
• Track Flaky Tests: Keep a list or dashboard of known flaky tests, their status, and assigned owners. Bring them up in daily standups so they aren't forgotten.
• Set Clear Goals: Commit to fixing a specific number or percentage of flaky tests within a set timeframe.
• Celebrate progress: Recognize and appreciate those who fix flaky tests. Positive feedback motivates the team to continue improving the test suite.

Conclusion

Flaky tests are not just minor annoyances. They waste valuable time, break your team's trust, and slow development. The good news is you don't have to tackle everything at once. Start with one of these ideas: fix a single flaky test each sprint, ensure your tests use isolated data, wait for specific conditions instead of using fixed delays, run tests in parallel, quarantine problematic tests, or replace extensive end-to-end tests with smaller, more focused tests. Adopting just one is a big step toward making your test suite more reliable.

Think of your test suite like that junk drawer: if you clean it up regularly, it stays helpful and easy to manage. Pick one flaky test that causes frequent trouble and fix it first. That small success will motivate your team and make your testing smoother.

For more details, you can watch my talk "Testing on Thin Ice: Chipping Away at Test Unpredictability" or you can get a free copy of my eBook "Stop Rerunning, Start Shipping: 7 Strategies to Eliminate Flaky Tests".

The post Eliminating Flaky Tests to End World Hunger appeared first on foojay.

In this episode of the Foojay Podcast, we're bringing you something special: a full batch of hallway-track conversations recorded live at VoxxedDays Amsterdam.

Fifteen guests, one conference, and one theme that kept coming back, whether we planned it or not: Java has grown up quietly, steadily, and in ways that still surprise people who haven't looked lately. We talked about migrating between versions, new features in the latest Java releases, authorization done right, AI-assisted coding, cryptography, containers, open-source contributions, GDPR data experiments, and, yes, the things people hate about Java but secretly love.

I spoke with Ko Turk, who organized this very conference, Johannes Bechberger, Lutske de Leeuw, Aicha Laafia, Marit van Dijk, Adele Carpenter, Patrick Baumgartner, Sohan Maheshwar, Jeroen Egelmeers, Erwin Manders, Alexander Shopov, Maarten Verburg, Arjan Tijms, Joost Kaan, and Stephan Janssen.

That's a lot of people. That's a lot of opinions. And somehow, they mostly agree: update your JDK, read your code, and please talk to your actual users.

YouTube

Podcast Apps

You can listen and subscribe to the Foojay Podcast on:

• Spotify
• Apple Podcasts
• And most others...

Content

00:00 Introduction

00:30 Ko Turk

• https://www.linkedin.com/in/ko-turk-b271b929/
• Organizer of VoxxedDays Amsterdam
• Migrating between Java versions

02:25 Johannes Bechberger

• https://www.linkedin.com/in/johannes-bechberger/
• Java is boring, and that's why it's brilliant
• Java 26 test it, but not in production
• JFR improvements in the latest versions

06:28 Lutske de Leeuw

• https://www.linkedin.com/in/lutske/
• Volunteer at the conference
• Java is boring, and that's why it's brilliant
• Java 5 till 26 evolutions

10:35 Aicha Laafia

• https://www.linkedin.com/in/aicha-laafia-0266a6126/
• Lambda stream gatherers in Java 25
• Simpler and more fun code
• Update your JDK!

16:16 Marit van Dijk

• https://www.linkedin.com/in/maritvandijk/
• Fun in coding, write Java the playful way
• Java evolutions and how writing code has evolved
• Importance of code reading with AI-assisted coding

22:04 Adele Carpenter

• https://www.linkedin.com/in/adele-carpenter-a988623a/
• The things I hate about Java, but actually love it

27:37 Patrick Baumgartner

• https://www.linkedin.com/in/patbaumgartner/
• Organizing VoxxedDays Zurich
• Spring Boot optimization
• Using Buildpacks to create better containers

35:02 Sohan Maheshwar

• https://www.linkedin.com/in/sohanmaheshwar/
• Authorization, the good way
• JWT is a bad idea

38:34 Jeroen Egelmeers

• https://www.linkedin.com/in/jegelmeers/
• https://craftingaiprompts.org/documentation/se-framework/craft-framework
• AI, prompt engineering, agentic programming
• The CRAFT Framework: Orchestrating Agentic Flow
• The importance of interacting with your end-users

43:32 Erwin Manders

• https://www.linkedin.com/in/erwinman/
• Cryptography, digital signatures, and securing data and messages
• Comparing Kotlin and Java

45:12 Alexander Shopov

• https://www.linkedin.com/in/alshopov/
• Developer at Uber
• Comparing different languages: Java, Python, Go
• How Java is modernizing by learning from other languages

49:18 Maarten Verburg

• https://www.linkedin.com/in/maartenverburg/
• Using your own GDPR data for fun experiments
• Comparing early Java with the current status
• Java Streams the most important change

52:35 Arjan Tijms

• https://www.linkedin.com/in/arjantijms/
• https://omnifish.ee/
• Jakarta Faces, Security, Authentication and Authorization, EE,...
• Jakarta specs are used in Spring
• How Java evolved and is still evolving
• How can you contribute to opensource

59:55 Joost Kaan

• https://www.linkedin.com/in/joost-kaan/
• What you can learn at a conference, besides the expected language-related talks
• AI influences on the developer work
• Contributing to the Java community, AI user group

01:03:52 Stephan Janssen

• https://www.linkedin.com/in/stephanjanssen/
• https://geniebuilder.ai/
• The importance of the "Hallway Track" where you can chat with like-minded people
• Using AI-assisted spec-driven coding
• Talking to your end-user becomes more important than ever

01:09:00 Conclusion

The post Foojay Podcast #93: Update Your JDK, Read More Code, and Talk to Your Users: Interviews From VoxxedDays Amsterdam appeared first on foojay.

In this short, practical talk DIY Technical Marketing, Real World Tips For Building A Successful Developer Brand, delivered at Jfokus 2026 conference, Payara Community Manager Dominika Tasarz-Sochacka explores why personal branding matters for developers and how even small, intentional actions can make a real difference over time.

Drawing on real world examples from years of working with Java developers, the session focuses on three core ideas:

• understanding the value of personal branding in the tech industry
• identifying what makes you unique and how to communicate it clearly
• taking simple first steps to build visibility without turning it into a full time job

This talk is designed to be approachable and realistic, especially for developers who want to focus on building great software while still investing in their long term career growth.

The post Watch the Recording: DIY Technical Marketing for Java Developers appeared first on foojay.

The 11th edition of DevBcn, the developer's conference in Barcelona is coming next June. The perfect place to have great technology talks , perfect weather , amazing food , and an unforgettable experience .

It will be hosted on the 16th and 17th of June 2026, in the World Trade Center Conference Center, having 4 rooms with talks in parallel during the 2 days of the conference : Java/JVM, AI, Cloud, Frontend, Managing and Soft skills.

Don't miss the opportunity and register now with discounted prices , submit your talk to the CFP (closing in 10 days) , and contact us if your company could be interested on the sponsorship

www.devbcn.com

The post DevBcn, the developers’ conference in Barcelona appeared first on foojay.

FOSDEM 2026: A Live Snapshot of Open Source

(a.k.a. “So… what did you do this weekend?”)

I’m back from four days in Brussels and the uniquely exhausting experience that is FOSDEM. Mentally fried. Physically wrecked. Entirely glad I went.

The Chaos and the Crowd

Around 8,000 people made the trip this year. Some arrived for the first time; many returned as annual pilgrims.

FOSDEM remains a strange outlier in the modern conference world: free to attend, no registration gatekeeping, and no sponsors dictating the tone. You just turn up.

Its official description, “a free event for software developers to meet, share ideas and collaborate”, is technically accurate and utterly inadequate.

FOSDEM isn’t a conference so much as a live snapshot of the open source ecosystem in action.

In 2026, that snapshot featured 1,000+ sessions and nearly 1,200 speakers across ~70 tracks. Organizers squeezed them into 37 rooms on the Université Libre de Bruxelles Solbosch campus. Do the maths, and you quickly realise something important: you are not there to consume everything. You are there to sample the firehose.

Navigating the Firehose

The organizers stream and record most talks (https://video.fosdem.org/2026/), which is a mercy. Physically moving between rooms is often futile. Staff strictly enforce capacity limits; you can arrive 30 minutes early and still lose out. The organisers never compromise on safety or timing. That discipline is the only reason the whole thing works at all.

So why go in person when you could watch from your sofa?

Because of who fills the rooms. When you strip away the PR layer, FOSDEM brings together the real movers: project founders, maintainers, and foundation reps. You’ll find lawyers, researchers, and distro builders sitting next to compiler engineers, students, and the people quietly keeping production systems alive.

No one pitches here. You get progress, blockers, failed experiments, and difficult questions. All aired publicly. Where else can you hear CycloneDX and SPDX contributors debating SBOM reality rather than policy theory? Where else can you ask a CRA-focused lawyer naïve but necessary questions without being sold a compliance product?

FOSDEM is the heartbeat of open source. It is a reliable way to distinguish what’s real from what’s hype. Ideas that survive here tend to matter. Ideas that don’t… don’t.

Trends and Tensions in 2026

What did FOSDEM 2026 actually tell us?

The familiar themes all appeared: AI, software supply chains, security, and the CRA. We saw robotics, compilers, Linux distros, and embedded systems. If it’s open source—from QA and mobile to radio and model railways—it was likely there.

I learnt a lot and met new people. I discussed the latest developments with experts in the areas I care about and came away with plenty to think about.

One telling gap appeared this year: no dedicated Java room. While a small Java presence remained across the tracks, the usual JVM-centric room was missing. I spent time with the Foojay.io folks discussing whether that absence matters.

For 2027, we’re considering a proposal for a Java Users room. We want to focus deliberately above the JVM and JDK, looking at how Java works in modern systems, supply chains, CI/CD, and regulated environments.

FOSDEM 2026 made one thing clear:

The hardest problems aren’t language features anymore. They are how we build, ship, and sustain software. AI included.

Security as Engineering, Not Defense

Security conversations threaded the event, though they often appeared indirectly. Speakers framed them as good engineering rather than reactive cyber defence. We talked about hardening build systems, reducing attack surfaces, and improving dependency hygiene. It felt less like “panic patching” and more like “this is how things should have been built.”

A noticeable urgency accompanied this, occasionally bordering on anxiety or a shared weariness. Technical collaboration is losing the race against legal obligation. The work needed to make software ecosystems safer is real and ongoing, but compliance deadlines now drive it more than shared engineering goals.

The Economics of "Free"

Open source is approaching a watershed moment.

Legislation like the Cyber Resilience Act (CRA) is reshaping expectations, responsibilities, and liability. Yet funding models for this work remain unclear, fragmented, or missing entirely.

Maintainers feel it. Foundations feel it. Downstream users are only just starting to notice.

One standout talk captured this tension perfectly: Michael Winser’s “The Terrible Economies of Package Registries.” He provided an evidence-rich look at how the assumption that “open source is free” collapses.

Once you factor in infrastructure, security, compliance, and abuse prevention, the math changes.

As open source becomes less free in economic terms...

Organisations are becoming more selective about what they use. Pay-to-download might not change behaviour first, but the equations are shifting. Our relationship with open source is changing because the world is changing.

AI accelerates this pressure; legislation compounds it. Together, they are distorting the economics of open source consumption in ways we are only beginning to understand.

A Practical Call to Action

So what should you actually do?

This article started as an ode to open source, and it still is. But nostalgia won’t keep systems compliant or safe. The good news is that the first responses require solid engineering, not ideology.

1. Know your software supply chain intimately

Not approximately. Not via a quarterly report. You must know what’s in production well enough to find vulnerabilities before regulators or attackers do.

FOSDEM saw intense discussion regarding supply chain security, SBOMs, and PURLs. Simplistically—since I am not a lawyer—demonstrating control over what you ship requires knowing what you ship. That 'demonstration' is quickly becoming a hard compliance requirement.

2. Make your CI/CD pipelines boringly efficient

Updates to the OS, dependencies, and tooling have to be routine, not heroic. If updates are painful, the next compliance deadline or vulnerability disclosure becomes an existential risk.

3. Establish a support posture for every component

That includes open source. You must know when your dependencies reach EOL, your legal exposure when that happens, and your technical options.

If upgrading is too risky or too slow, more commercial support is appearing to help with EOL open source. Being in control of your software means being able to explain how you resolve security issues.

Whatever path you choose: planning for frequent upgrades, yearly modernisation, the draconian withdrawal of applications, or simply buying a support contract, you must be able to deliver. Auditors will not accept hand-waving or "we'll figure it out when it happens" type of answers.

Silver Linings

The points above all come down to having solid engineering foundations. New tools are arriving to make things easier and many were on display at FOSDEM. They will , eventually, help you take the drama out of delivering secure software, whether AI is included or not.

Many non-technical elements remain unresolved though . We still need cultural and economic shifts.

FOSDEM 2026 showed us how vital and dynamic open source is and how it is rising to the challenges we all face, but perhaps we saw the beginning of the end of the "just more tech" era.

We are finally acknowledging that cultural and economic changes will rewrite our relationship with software.

I’d rather hear that now, out loud and in public from the people doing the work, than from a regulator, a breach report, or a courtroom.

FOSDEM 2027 is looking like the place to be next year.

Time to mark your calendar.

The post FOSDEM 2026 and the Open Source Firehose appeared first on foojay.

If you are like me, get the adrenaline rush of getting up on stage and can’t wait to share things that you experienced and learned, then submitting talks to conferences and local meetups excites you.

But as much as you are proud and happy when you are accepted to present, normally there is a lot of work before that for the reviewers and organizers to find the right presentation that resonates with the attendees and fits the whole program.

Drawing on my experience as a reviewer for Voxxed Days Amsterdam over the past two years, as well as organizing Microsoft internal meetups and roundtables and my previous involvement with Capgemini’s Java community, I have dedicated significant time to selecting presentations and talks.

So, this is my humble effort to share a few criteria that have guided me (and others) in choosing your submissions for inclusion. This is not an exhaustive list but what we see most.

Speaker/Talk related reasons

 AI was used to restructure and refine the grammar and sentences, it had no influence on the idea or the structure of this post.

Special Thanks to: Marit van Dijk, Julien lengrand-lambert, Sander Mak, Simone de Gijt, Kaya Weers, Ko Turk and Wilco Burggraaf for helping me shape this post.

The post Why is my Talk selected? Reflections from a Program Committee Reviewer appeared first on foojay.

What turns a nervous first-timer into a confident conference speaker? Let's find out.

This the last Foojay Podcast of 2025 and also the last one with interviews recorded at the Devoxx and JFall conferences. Maybe you're already thinking about your goals for 2026: organizing a meetup, submitting your first conference talk, or taking a bigger role in the Java community. If that sounds like you, this episode is for you.

I talked with the people behind these conferences and developers at different stages of their speaking journey. At Devoxx, I spoke with Stephan Janssen, who has been organizing Devoxx for 20 years, Susanne Pieterse, about what makes conferences valuable for learning, and Daniël Floor, a developer just starting out with public speaking. At JFall, I caught up with organizers Martin Smelt and Brian Vermeer, Berwout de Vries Robles, who coaches new speakers, and Annelore Egger about her journey from developer to conference speaker.

You'll hear practical advice about what makes a good CFP, why conference organizers actively want new speakers, and how the Java community is set up to help you get started. Whether you're thinking about submitting your first talk or curious about what goes into organizing a conference, there's something here for you.

YouTube

Podcast Apps

You can listen and subscribe to the Foojay Podcast on:

• Spotify
• Apple Podcasts
• And most others...

Content

00:00 Introduction of topic and guests

01:33 Stephan Janssen

• https://www.linkedin.com/in/stephanjanssen/
• Devoxx Organizer

07:03 Martin Smelt

• https://www.linkedin.com/in/martin-paul-smelt-8b699a8/
• JFall Organizer

13:27 Brian Vermeer

• https://www.linkedin.com/in/brianvermeer/
• JFall Organizer and speaker
• Tips for speakers, writing a CFP
• Join a JUG!

21:02 Annelore Egger

• https://www.linkedin.com/in/anneloredev/
• How to become a speaker

27:43 Daniël Floor

• https://www.linkedin.com/in/dani%C3%ABl-floor-266652208/
• Taking the first steps into public speaking
• Finding your speaking topic

31:28 Berwout de Vries Robles

• https://www.linkedin.com/in/berwout-de-vries-robles/
• Tips for speakers
• Propose a talk to speak at a JUG

37:08 Susanne Pieterse

• https://www.linkedin.com/in/susannepieterse/
• Learning at conferences, RAG, and other topics
• Meeting and talking to the presenters and specialists at a conference
• CO-organizer of ML Con and DevOpsCon in Amsterdam
• https://mlconference.ai/
• https://devopscon.io/amsterdam/

41:20 Conclusion

The post Foojay Podcast #88: From Code to Stage: Organizing Conferences and Finding Your Voice as a Speaker appeared first on foojay.

The AI revolution isn't replacing Java developers. No, it's forcing us to think harder.

Welcome to another episode of the Foojay Podcast! Today, we're talking about AI and Java, how it's changing the way we work, what we need to watch out for, and why understanding what's really happening matters more than ever.

I recorded interviews at Devoxx and JFall and spoke with people who build and use this technology every day.

Marianne Hoornenborg opened my eyes to something important: every time an AI generates a token, there's a massive amount of computation happening behind the scenes.

Viktor Gamov and Baruch Sadogursky did something really cool: they tested six different AI coding tools live on stage with the same task. The results were all over the place! But they found that the tools with access to good documentation performed much better.

Stephen Chin showed me how graph databases can make AI responses more reliable by providing a solid source of truth rather than relying on vector search.

Mario Fusco works on LangChain4J, a leading Java framework for AI. He explained that breaking down large tasks into smaller ones and using specialized agents can help reduce errors—hallucinations, as they're called.

Jeroen Benckhuijsen and Martijn Dashorst shared their experiences working with enterprise Java. Even as frameworks are becoming lighter and we're running everything in containers, there are still complex problems that require real developer expertise.

Maarten Mulders reminds us that AI is a tool, not a replacement—especially when you're solving problems no one has tackled before. You still need to know what you're doing.

And finally, Simon Maple from Tessel discussed moving beyond vibe coding towards a more reliable, production-ready approach, using specifications to guide AI tools.

YouTube

Podcast Apps

You can listen and subscribe to the Foojay Podcast on:

• Spotify
• Apple Podcasts
• And most others...

Content

00:00 Introduction of topics and guests

02:12 Marianne Hoornenborg

• https://www.linkedin.com/in/mhoornenborg/
• The Simple Math behind AI
• The cost of tokens when using LLMs

06:54 Viktor Gamov and Baruch Sadogursky

• https://www.linkedin.com/in/vikgamov/
• https://www.linkedin.com/in/jbaruch/
• Robocoders, about the many agentic tools that can be used for vibe coding
• https://context7.com/

16:24 Stephen Chin

• https://www.linkedin.com/in/steveonjava/
• Graph versus relational databases
• Explaining MCP and Agents

23:09 Mario Fusco

• https://www.linkedin.com/in/mario-fusco-3467213/
• AI and LangChain4j in Quarkus
• Coding tools with AI

35:43 Jeroen Benckhuijsen

• https://www.linkedin.com/in/jeroenbenckhuijsen/
• Java in business, Evolutions in Java
• Making use of containers and Kubernetes
• Learning from the community

41:44 Martijn Dashorst

• https://www.linkedin.com/in/dashorst/
• Investigating an OOM-killer in Kubernetes with the help of AI

49:37 Maarten Mulders

• https://www.linkedin.com/in/mthmulders/
• How AI may impact our jobs

56:13 Simon Maple

• https://www.linkedin.com/in/simonmaple/
• AI developer tool Tessl
• Spec-driven vibe coding
• Secure AI development

01:02:12 Conclusion

The post Foojay Podcast #86: Agents, MCP, and Graph Databases: Java Developers Navigate the AI Revolution appeared first on foojay.

What if the future of Java depends on who we invite to learn it today?

In this Foojay Podcast, we're diving into something that affects all of us in the Java community: How can we inspire the next generation of developers, and how do we make the developer world more inclusive?

In this episode, you'll hear four incredible guests who are actively working to make tech more accessible and inclusive. First, Daniel De Luca talks about Devoxx for Kids and how they support underprivileged students in IT education. Then Kenny Schwegler shares his insights on how we can actively promote diversity and inclusion in tech. Cassandra Chin, the youngest Java Champion and author, talks about inspiring young coders through hands-on projects and making technology fun. And finally, Igor De Souza discusses his mission to bring Java into Raspberry Pi education and bring more Java into coding clubs worldwide.

These conversations share one message: Talent is everywhere, but opportunity isn't. And we have the power to change that!

YouTube

Podcast Apps

You can listen and subscribe to the Foojay Podcast on:

• Spotify
• Apple Podcasts
• And most others...

Content

01:19 Daniel De Luca

• https://www.linkedin.com/in/danieldeluca/
• Founder Devoxx4Kids
• Activities of Devoxx4Kids
• How to inspire children of all ages to get interested in technology

14:24 Kenny Schwegler

• https://www.linkedin.com/in/kenny-baas/
• How to build inclusive, diverse teams
• How the IT industry became male-focused because of IBM marketing
• Books:
  • https://www.manning.com/books/collaborative-software-design
  • https://learningsystemsthinking.com/

26:07 Cassandra Chin

• https://www.linkedin.com/in/cassandra-chin-developer/
• Inspiring children and parents into technology
• Fun projects to introduce engineering to children
• Book:
  • https://www.amazon.nl/Raising-Young-Coders-Teaching-Programming/dp/B0DVBQZ483
  • 20% Discount code on the Springer website "APAUT"
    • https://link.springer.com/book/10.1007/979-8-8688-1393-1

32:45 Igor De Souza

• https://www.linkedin.com/in/igfasouza/
• Java in code clubs like CoderDojo
• Java in space
• Collecting Java tutorials and courses for children
• Java Catalog on Foojay GitHub
  • https://github.com/foojayio/java-education-catalog
• Pi4J library
  • https://www.pi4j.com/
• HelloWorld magazine:
  • https://downloads.ctfassets.net/oshmmv7kdjgm/6jGvFLH86Ems5AJR84Krsk/3888c571ddc1543c9cdb01ce5eff616d/HelloWorld28.pdf

55:27 Conclusions

The post Foojay Podcast #85: Code, Community, and Opportunity: Making Tech Accessible for Everyone appeared first on foojay.