DEV Community: Bruno Borges

How I Automated Weekly Twitter/X Posts With GitHub Actions

Bruno Borges — Tue, 14 Apr 2026 16:06:59 +0000

Every Monday at 10 AM Eastern, @javaevolved now tweets a modern Java pattern — automatically. No manual steps, no third-party services, no cron servers. Just a GitHub Actions workflow, a couple of JBang scripts, and the Twitter API.

Here's how it works, and how you can do the same for your own project.

The Problem

Java Evolved is a static site with 113 code patterns showing the old way vs. the modern way to write Java. Each pattern has a title, summary, old/modern approach labels, JDK version, and a link to its detail page.

I wanted to promote each pattern on Twitter — one per week, in random order, cycling forever. The requirements:

Fully automated — no manual tweeting
Pre-drafted tweets — reviewable and editable before they go live
Resumable — survives failures, picks up where it left off
Auditable — git history shows what was posted and when
Zero infrastructure — no servers, no databases, no paid services

The Architecture

The system has three components:

content/*.yaml → [Queue Generator] → social/queue.txt
                                    → social/tweets.yaml
                                    → social/state.yaml

social/* → [Post Script] → Twitter API v2 → updated state

GitHub Actions cron → runs Post Script every Monday

Everything lives in the repository. State is tracked via committed files, not external databases.

Component 1: The Queue & Tweet Generator

File: html-generators/generatesocialqueue.java

A JBang script that scans all content YAML files, shuffles them randomly, and produces three files:

social/queue.txt — the posting order, one category/slug per line
social/tweets.yaml — pre-drafted tweet text for each pattern
social/state.yaml — a pointer tracking where we are in the queue

The tweet template looks like this:

☕ {title}

{summary}

{oldApproach} → {modernApproach} (JDK {jdkVersion}+)

🔗 https://javaevolved.github.io/{category}/{slug}.html

#Java #JavaEvolved

The generator also validates that every tweet fits within Twitter's 280-character limit. If a summary is too long, it's automatically truncated with an ellipsis. Of the 113 patterns, 12 needed truncation.

Handling New Patterns

When you re-run the generator after adding new content files, it detects new patterns and appends them to the end of the existing queue — preserving the current order and any manual tweet edits. Deleted or renamed patterns are automatically pruned.

Use --reshuffle to force a full reshuffle when the cycle is exhausted.

Component 2: The Post Script

File: html-generators/socialpost.java

Another JBang script that:

Reads the current index from social/state.yaml
Looks up the next pattern key in social/queue.txt
Retrieves the pre-drafted tweet text from social/tweets.yaml
Posts to the Twitter API v2 using OAuth 1.0a
Updates the state file only after confirmed API success

OAuth 1.0a in Java

I initially planned to use a shell script with curl and openssl for OAuth signing. That turned out to be a bad idea — percent-encoding, signature base strings, and nonce generation are error-prone in Bash.

Instead, the post script uses Java's built-in java.net.http.HttpClient and javax.crypto.Mac for HMAC-SHA1 signing. Here's the core of the OAuth signature:

// Build signature base string
var paramString = oauthParams.entrySet().stream()
    .map(e -> percentEncode(e.getKey()) + "=" + percentEncode(e.getValue()))
    .collect(Collectors.joining("&"));

var baseString = method + "&" + percentEncode(url) + "&" + percentEncode(paramString);
var signingKey = percentEncode(consumerSecret) + "&" + percentEncode(tokenSecret);

// HMAC-SHA1
var mac = javax.crypto.Mac.getInstance("HmacSHA1");
mac.init(new javax.crypto.spec.SecretKeySpec(
    signingKey.getBytes(UTF_8), "HmacSHA1"));
var signature = Base64.getEncoder().encodeToString(
    mac.doFinal(baseString.getBytes(UTF_8)));

The script also supports --dry-run to preview the next tweet without posting:

$ jbang html-generators/socialpost.java --dry-run

Queue has 113 entries, current index: 1
Pattern: language/guarded-patterns
Tweet (200 chars):
---
☕ Guarded patterns with when

Add conditions to pattern cases using when guards.

Nested if → when Clause (JDK 21+)

🔗 https://javaevolved.github.io/language/guarded-patterns.html

#Java #JavaEvolved
---
DRY RUN — not posting.

Component 3: The GitHub Actions Workflow

File: .github/workflows/social-post.yml

name: Weekly Social Post

on:
  schedule:
    - cron: '0 14 * * 1'  # Every Monday at 14:00 UTC (10 AM ET)
  workflow_dispatch:       # Manual trigger

concurrency:
  group: social-post
  cancel-in-progress: false

jobs:
  post:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-java@v5
        with:
          distribution: 'temurin'
          java-version: '25'
      - uses: jbangdev/setup-jbang@main

      - name: Post to Twitter
        env:
          TWITTER_CONSUMER_KEY: ${{ secrets.TWITTER_APP_CONSUMER_KEY }}
          # ... other secrets
        run: jbang html-generators/socialpost.java

      - name: Commit updated state
        run: |
          git add social/state.yaml
          git commit -m "chore: update social post state [skip ci]"
          git pull --rebase
          git push

A few details worth noting:

concurrency group prevents double-posts if a manual dispatch overlaps with the cron
[skip ci] in the commit message prevents the state update from triggering other workflows
Social files live in social/, not content/ — the deploy workflow watches content/**, so keeping state separate avoids unnecessary site rebuilds
git pull --rebase before push handles the rare case where another commit lands between checkout and push

The Economics

Twitter's API pricing means each tweet costs about $0.01. With 113 patterns posted weekly:

~$0.52/year
~2.2 years of unique content per cycle before reshuffling

That's essentially free for a perpetual social media presence.

Built in a Single Copilot CLI Session

This entire feature — the queue generator, the post script, the GitHub Actions workflow, the tweet drafts, the documentation updates — was built in a single interactive session with GitHub Copilot CLI. From planning to the first live tweet, everything happened in the terminal.

The session included planning the architecture, getting a rubber-duck critique (which caught several issues — like using shell for OAuth signing and putting state files where they'd trigger deploys), implementing all three components, testing locally with --dry-run, committing, pushing, and triggering the first real tweet.

You can read the full session transcript here: gist.github.com/brunoborges/40ef1b5e9b05de279dab64e443b96a11

What I'd Do Differently

Add Bluesky support — the AT Protocol API is simpler than Twitter's OAuth 1.0a. The architecture already supports it; just add a second API call in the post script.
Content hash tracking — if a pattern's title or summary changes, the pre-drafted tweet goes stale. A hash per entry would flag which drafts need regeneration.

Try It Yourself

The entire implementation is open source at github.com/javaevolved/javaevolved.github.io. You'll need:

A Twitter Developer account with OAuth 1.0a credentials (Read + Write)
Java 25+ and JBang
Content in YAML with title, summary, oldApproach, modernApproach, jdkVersion, category, and slug fields

Generate the queue, review the drafts, push, and let GitHub Actions handle the rest.

Follow @javaevolved for a new modern Java pattern every Monday.

Translating a Website into 8 Languages with AI Agents in One Night

Bruno Borges — Thu, 26 Feb 2026 05:58:07 +0000

How I used Claude Sonnet 4.6 and fleets of GitHub Copilot Coding Agents to internationalize java.evolved — from spec to deployment

java.evolved is a static site I built to showcase modern Java patterns side-by-side with their legacy equivalents. 112 patterns across 11 categories — language, collections, streams, concurrency, and more — each with code comparisons, explanations, and curated documentation links. All generated from YAML content files by a JBang-powered Java build script.

By the end of February 25, the entire site was English-only. By the morning of February 26, it was available in 9 languages — English, German, Spanish, Portuguese (Brazil), Simplified Chinese, Arabic, French, Japanese, and Korean — with full RTL support for Arabic. The total human effort was a few hours of prompting, reviewing PRs, and filing one bug.

This is the story of that experiment.

The Architecture Decision: Let the AI Draft the Spec

The first step wasn't writing code. It was writing a specification.

I opened issue #74 — "Plan architectural change for i18n" — and assigned it to a Copilot Coding Agent. The prompt was simple: propose an architectural plan for internationalizing the website, considering the existing static-site structure.

The agent (PR #75) came back with a comprehensive i18n specification that addressed:

Two-layer translation model: UI strings (labels, nav, footer) separated from content translations (pattern titles, explanations, summaries)
Partial translation files: Translation files contain only translatable fields. Structural data (code snippets, navigation links, metadata) always comes from the English source of truth
Graceful fallback: Missing translations fall back to English with a build-time warning — no page is ever blank
Locale registry: A simple locales.properties file drives the entire build pipeline and language selector
AI-friendly design: The architecture was explicitly designed so that an AI receives the full English content and returns a partial translation file — no field-filtering logic needed in the prompt

This last point proved prescient. The clean separation between "what changes per locale" and "what stays constant" meant each translation task was self-contained and parallelizable.

After iterating through review comments over 5 days (the original PR had 12 comments of back-and-forth), the spec was merged on February 25.

Phase 1: Building the Infrastructure

With the spec in hand, I coordinated an agent locally with Coilot CLI to implement the core i18n infrastructure in PR #83 — the generator changes that made everything locale-aware:

The generate.java build script learned to iterate all locales from locales.properties
Template tokens like {{sections.codeComparison}} replaced hard-coded English strings
hreflang meta tags, a locale picker dropdown, and client-side locale detection were added
The resolveSnippet function loads translated content overlaid onto the English base, falling back gracefully when a translation doesn't exist

This was the only PR that required significant intervention. Everything after it was delegation.

Phase 2: The First Translations (Spanish + Portuguese)

The first real translation — Spanish — came in PR #84. This PR also migrated the English content files from JSON to YAML for improved readability — a format change that the AI handled naturally since the generator already supported multiple formats.

Brazilian Portuguese followed immediately in PR #85, completing all 112 pattern files (going from 3/112 translated to 112/112 — 100% coverage). These first two translations validated the architecture and surfaced a CI issue: the deploy workflow's path triggers didn't match YAML files or the translations/ directory. A quick fix in PR #86 resolved that.

Phase 3: The Fleet — 6 Languages in Parallel

This is where things got interesting. With the architecture proven and two complete translations validated, I launched a fleet of Copilot Coding Agents — multiple agents working in parallel, each assigned a single language. I used the Copilot CLI /delegate command to dispatch them asynchonously, all with the same prompt:

PR	Language	Agent	Time to PR
#87	Japanese (日本語)	Copilot	~36 min
#88	German (Deutsch)	Copilot	~35 min
#89	French (Français)	Copilot	~32 min
#90	Chinese 中文 (简体)	Copilot	~58 min
#91	Arabic (العربية)	Copilot	~53 min
#94	Korean (한국어)	Copilot	~24 min

Each agent independently:

Read the i18n spec and understood the file structure
Created a UI strings YAML file (translations/strings/{locale}.yaml) with 60+ translated keys
Generated 112 content translation YAML files — one per pattern, across all 11 categories
Registered the locale in locales.properties
Opened a PR with a detailed description of what was translated

All six PRs were opened within a span of about 12 minutes (2:33 AM to 2:45 AM) and were all merged within the next hour. No translation conflicts, no merge issues, no structural errors. The partial-file architecture did exactly what it was designed to do — each agent's output was isolated to its own locale directory.

The Numbers

By the time the fleet finished:

8 locales fully supported (besides English)
112 patterns × 8 translated locales = 896 content translation files
8 UI string files with 60+ keys each
~1,008 generated HTML pages (112 pages × 8 locales)
8 localized search indexes (snippets.json per locale)

The Arabic Surprise: RTL Support

The most impressive moment was the Arabic translation (PR #91). The agent not only translated, it also noted that Arabic is a right-to-left language and proactively added RTL infrastructure:

Added dir="{{htmlDir}}" to the <html> tag in both templates
Modified the generator to resolve htmlDir to "rtl" for Arabic and "ltr" for all other locales
Updated the Python benchmark generator to pass the new token

This was a genuinely thoughtful architectural change that I hadn't explicitly requested. The agent understood that Arabic support implies RTL layout and acted on it.

The One Bug

Of course, it wasn't perfect. When dir="rtl" is applied globally, the browser flips everything — including Java source code blocks and the navigation bar, which IMO should always be LTR regardless of locale. I spotted this when reviewing the deployed site and filed issue #96.

A Copilot Coding Agent fixed it in PR #97 within minutes, adding targeted CSS overrides:

[dir="rtl"] nav,
[dir="rtl"] .nav-inner {
  direction: ltr;
}

[dir="rtl"] pre,
[dir="rtl"] code,
[dir="rtl"] .code-text,
[dir="rtl"] .card-code,
[dir="rtl"] .compare-code {
  direction: ltr;
  text-align: left;
  unicode-bidi: embed;
}

Arabic prose continues to render RTL. Java code stays LTR. One bug, one issue, one PR, fixed in minutes. That's the entire human intervention required for 8-language support.

Why It Worked: Architecture as Force Multiplier

This experiment succeeded because of deliberate architectural decisions, not just because of a magic AI prompt. A few design choices made parallelized AI translation almost trivially easy:

1. Source of Truth Separation

Content files contain both translatable text and structural data (code, navigation, metadata). But translation files contain only the translatable fields. The generator overlays translations onto the English base at build time. This means:

AI agents can't accidentally modify code snippets or break navigation
Translation files are small and self-contained
Structural changes to the English source propagate immediately without needing to update translations

2. Partial File Fallback

If a pattern has no translation file for a locale, the site shows the English content with an "untranslated" banner. This means:

Partial translations are always valid
New patterns added in English are immediately visible in all locales
There's no "all or nothing" pressure on translation completeness

3. Convention Over Configuration

Each locale follows the same directory structure. Adding a new language is a checklist:

Add a line to locales.properties
Create translations/strings/{locale}.yaml
Create files under translations/content/{locale}/

No code changes needed in the generator. No template modifications. The AI spec anticipated this workflow, and the agents followed it exactly.

Lessons Learned

What Went Well

Spec-first approach: Having the AI draft the specification before any implementation meant the architecture was explicitly designed for AI-driven translation from day one
Fleet parallelism: Six language translations running simultaneously with zero conflicts demonstrates that well-isolated task boundaries enable effortless parallelization
Proactive problem-solving: The Arabic agent identifying and implementing RTL support without being explicitly asked shows that LLMs can reason about the downstream implications of their translations
Technical term preservation: Across all 9 languages, Java API names, annotations, JDK versions, and code examples were correctly left in English — the agents understood what should and shouldn't be translated in a technical context

What Required Human Intervention

One bug: The RTL global flip affecting code blocks. This is a classic CSS gotcha that even experienced developers might miss on first pass. Filed as an issue, fixed by an agent in minutes
CI pipeline fixes: The deploy workflow needed path trigger updates after the JSON→YAML migration. A routine ops fix
Review and merge: Each PR needed a human to review and merge. The content quality was consistently good, but spot-checking translations in languages you speak is still important

The Timeline

Time (UTC)	Event
Feb 20, 20:33	Issue #74 opened — "Plan architectural change for i18n"
Feb 20, 20:33	PR #75 opened — i18n specification (by Copilot Agent)
Feb 25, 20:56	PR #75 merged (after 5 days of procrastination, and other projects at hand... finally!)
Feb 25, 23:49	PR #83 merged — core i18n infrastructure
Feb 26, 01:28	PR #84 merged — Spanish translation + JSON→YAML migration
Feb 26, 02:27	PR #85 merged — Complete Brazilian Portuguese (112/112)
Feb 26, 02:29	PR #86 merged — CI path trigger fix
Feb 26, 02:33–02:45	PRs #87–#91 opened — fleet of 6 language agents launched
Feb 26, 03:09–03:39	All fleet PRs merged (Japanese, German, French, Chinese, Arabic)
Feb 26, 03:51	PR #94 opened — Korean (final language)
Feb 26, 03:59	Issue #96 filed — Arabic RTL bug
Feb 26, 04:12	PR #97 merged — RTL fix
Feb 26, 04:15	PR #94 merged — Korean complete

From spec merge to 8-language site: ~7 hours. From fleet launch to all 6 languages merged: ~1 hour.

Conclusion

The experiment proved a simple thesis: if you design your architecture for AI-driven workflows, AI agents can do remarkable things.

I didn't build a custom translation pipeline or prompt-engineering framework. I wrote a specification. An AI agent drafted it, I refined it through code review, and then a fleet of agents executed against it. The architecture — partial files, fallback behavior, source-of-truth separation — did all the heavy lifting.

The result is a Java patterns reference site available in 8 languages, with 1,008 generated pages, serving developers who speak English, German, Spanish, Portuguese, Chinese, Arabic, French, and Korean. It handles right-to-left layouts. It has localized search. Every page has proper hreflang tags for SEO.

And the only bug was a CSS rule that took 13 minutes from report to fix.

The future isn't AI replacing developers. It's developers designing systems that let AI do what it's good at — repetitive, structured, parallelizable work — while humans focus on architecture, review, and the occasional RTL bug.

java.evolved is open source at github.com/javaevolved/javaevolved.github.io. The i18n specification lives at specs/i18n/i18n-spec.md.

Enabling AI Agents to Use a Real Debugger Instead of Logging

Bruno Borges — Mon, 16 Feb 2026 21:00:39 +0000

Every Java developer has been there. Something breaks, and the first instinct is to litter the code with System.out.println(">>> HERE 1"). Then HERE 2. Then HERE 3 — value is: " + x. Rebuild. Rerun. Stare at the console. Repeat.

We've been doing this for decades. And now, so have our AI agents.

When you ask an AI coding assistant to debug a Java application, it almost always reaches for the same playbook: add logging statements, recompile, rerun, read the output, and reason about what happened. It's the println debugging loop, automated — but it's still println debugging.

What if the agent could just... use a real debugger?

The JDK ships a perfectly good debugger. Nobody uses it.

Every JDK installation since the beginning of time includes jdb — the Java Debugger. It's a command-line tool that lets you set breakpoints, step through code, inspect variables, catch exceptions, and examine threads. It speaks the same JDWP protocol that IntelliJ and Eclipse use under the hood.

And it's purely text-based, which makes it a perfect tool for AI agents that operate through terminal commands.

The problem is that no agent knows how to use it. Until now.

Agent Skills: Teaching new tricks through Markdown

Anthropic's Agent Skills framework lets you package instructions, scripts, and reference material into a structured directory that AI agents can load dynamically. The format is simple: a SKILL.md file with YAML frontmatter and Markdown instructions, plus optional helper scripts and reference docs.

Think of a skill as a runbook that the agent reads just-in-time when it recognizes a relevant task. The key insight is progressive disclosure — the agent only loads the skill's description at startup (~100 tokens), and pulls in the full instructions only when it decides the skill is needed.

I decided to build one that teaches agents how to operate JDB.

Building the skill: a conversation with Copilot

The entire skill was built in a single conversation session with GitHub Copilot CLI. The process was surprisingly natural — I described what I wanted, and we iterated through research, design, implementation, and testing together.

The conversation started with a simple prompt:

"Java (the JDK) has a Debugger CLI. Let's build a skill so that AI agents can debug applications in real time."

Copilot researched the Agent Skills specification, studied the Anthropic public skills repository for patterns, read Oracle's JDB documentation, and then produced the complete skill — all within the same session.

What the skill contains

The resulting jdb-debugger-skill has a clean structure:

jdb-debugger-skill/
├── SKILL.md                        # Core instructions for the agent
├── scripts/
│   ├── jdb-launch.sh               # Launch a JVM under JDB
│   ├── jdb-attach.sh               # Attach to a running JVM
│   ├── jdb-diagnostics.sh          # Automated thread dumps
│   └── jdb-breakpoints.sh          # Bulk-load breakpoints from a file
└── references/
    ├── jdb-commands.md              # Complete command reference
    └── jdwp-options.md              # JDWP agent configuration

The SKILL.md opens with a decision tree — a pattern borrowed from Anthropic's own webapp-testing skill — that guides the agent to the right approach:

User wants to debug Java app →
  ├─ App is already running with JDWP agent?
  │   ├─ Yes → Attach: scripts/jdb-attach.sh --port <port>
  │   └─ No  → Can you restart with JDWP?
  │       ├─ Yes → Launch with: scripts/jdb-launch.sh <mainclass>
  │       └─ No  → Suggest adding JDWP agent to JVM flags
  │
  ├─ What does the user need?
  │   ├─ Set breakpoints & step through code → Interactive JDB session
  │   ├─ Collect thread dumps / diagnostics → scripts/jdb-diagnostics.sh
  │   └─ Catch a specific exception → Use `catch` command in JDB

Then it provides concrete debugging workflow patterns — how to investigate a NullPointerException, how to watch a method's behavior, how to diagnose a deadlock — written as step-by-step JDB command sequences the agent can follow.

The real test: debugging a buggy Swing app, live

To prove this wasn't just theoretical, we built a sample Swing application with four intentional bugs:

NullPointerException — processMessage() returns null for empty input
Off-by-one error — the warning counter always shows one less than actual
NullPointerException after clear — warningHistory is set to null instead of .clear()
StringIndexOutOfBoundsException — text.substring(0, 3) on input shorter than 3 characters

Then we debugged it. In the same conversation session. With the agent driving JDB.

The debugging session

The agent launched the app under JDB, set exception catches and method breakpoints, and ran the application:

> catch java.lang.NullPointerException
> catch java.lang.StringIndexOutOfBoundsException
> stop in com.example.WarningApp.showWarning
> run

When I clicked "Show Warning" in the Swing UI, JDB immediately hit the breakpoint. The agent stepped through the code, inspecting variables at each step:

Breakpoint hit: "thread=AWT-EventQueue-0", com.example.WarningApp.showWarning(), line=80
80            String text = inputField.getText();

AWT-EventQueue-0[1] next
Step completed: line=83
83            String processed = processMessage(text);

AWT-EventQueue-0[1] print text
 text = "bruno"

It stepped into processMessage, verified the return value, then stepped back out:

AWT-EventQueue-0[1] step
Step completed: com.example.WarningApp.processMessage(), line=105
105            String trimmed = message.trim();

AWT-EventQueue-0[1] step up
Step completed: com.example.WarningApp.showWarning(), line=83

AWT-EventQueue-0[1] print processed
 processed = "⚠ BRUNO ⚠"

Then came the moment where it caught the off-by-one bug red-handed. The agent stepped to the counter update and inspected the state:

AWT-EventQueue-0[1] print warningCount
 warningCount = 0

AWT-EventQueue-0[1] next
Step completed: line=93
93            counterLabel.setText("Warnings shown: " + (warningCount - 1));

AWT-EventQueue-0[1] print warningCount
 warningCount = 1

There it is. warningCount is 1, but line 93 displays warningCount - 1, which is 0. The agent identified the bug by observing the live state of the program at the exact line where the defect occurs — no logging, no guessing, no recompilation.

A small but important lesson: compile with `-g`

One interesting moment in the session: the first time we tried locals, JDB responded:

Local variable information not available. Compile with -g to generate variable information

The agent immediately recognized the issue, quit JDB, recompiled with javac -g (which includes debug symbols), and relaunched. This is exactly the kind of practical knowledge that a skill should encode — and that we later made sure to document in the SKILL.md.

Why this matters

Beyond `println` debugging

The standard AI debugging loop today looks like this:

Read the code
Add System.out.println or logging statements
Recompile
Run the program
Read the output
Reason about what happened
Modify the code
Repeat

With JDB, the agent can:

Set breakpoints at suspicious locations
Run the program
Inspect the actual runtime state — variable values, call stacks, thread states
Step through execution line by line
Catch exceptions at the exact throw site

This is a fundamentally different approach. The agent observes the program's behavior as it runs, rather than inferring it from log output after the fact.

Interactive debugging as a first-class agent capability

What makes this work so well is the combination of:

JDB being text-based — it reads commands from stdin and writes output to stdout, which is exactly how AI agents interact with tools
Agent Skills being just Markdown — no SDK, no API integration, no plugin framework. You write instructions in a .md file and the agent follows them
Helper scripts as black boxes — the agent runs scripts/jdb-attach.sh --port 5005 without needing to understand the script internals

The skill follows the same "black-box scripts" pattern used by Anthropic's own webapp-testing skill, which uses Playwright scripts the agent invokes without reading their source.

The shift from static analysis to dynamic observation

Most AI coding tools today work with static information — source code, type signatures, documentation. JDB gives agents access to dynamic information — what actually happens at runtime. This is especially valuable for:

Concurrency bugs — thread dumps and deadlock detection through JDB's threads and where all commands
State-dependent bugs — inspecting object fields and local variables at specific points in execution
Exception investigation — catching exceptions at the throw site rather than reading stack traces after the fact
Integration issues — attaching to running services to observe behavior with real data

Try it yourself

The skill is open source: github.com/brunoborges/jdb-debugger-skill

The repository includes a sample Swing app with the four intentional bugs described above, so you can reproduce the exact debugging session. The full conversation transcript is available as a GitHub Gist.

To get started:

/skill add jdb-debugger

Then just ask: "Debug my Java application — there's a NullPointerException I can't figure out."

What's next

This is a starting point. The skill currently covers the core JDB workflow, but there are natural extensions:

Conditional breakpoints and watchpoints for more surgical debugging
Integration with build tools — auto-detecting Maven/Gradle projects and compiling with -g before launching JDB
Remote debugging recipes — patterns for Kubernetes pods, Docker containers, and cloud-hosted JVMs
Composability with other skills — combining JDB debugging with code analysis or test-generation skills

The bigger takeaway is this: every command-line tool that developers use daily is a potential agent skill. Debuggers, profilers, database CLIs, network tools — they're all text-based interfaces waiting to be taught to AI agents.

The JDK gave us the debugger thirty years ago. We just needed to write the instructions.

How to Configure JDK 25 for GitHub Copilot Coding Agent

Bruno Borges — Thu, 05 Feb 2026 23:37:16 +0000

GitHub Copilot coding agent runs in an ephemeral GitHub Actions environment where it can build your code, run tests, and execute tools. By default, it uses the pre-installed Java version on the runner—but what if your project needs a specific version like JDK 25?

In this post, I'll show you how to configure Copilot coding agent's environment to use any Java version, including the latest JDK 25, ensuring that Copilot can successfully build and test your Java projects.

The Problem

When Copilot coding agent works on your repository, it attempts to discover and install dependencies through trial and error. For Java projects, this means:

Copilot might try to use an older JDK version pre-installed on the runner
Build failures occur if your project requires newer Java features (records, pattern matching, virtual threads, etc.)
Time is wasted as Copilot tries different approaches to fix JDK-related issues

The solution? Preconfigure Copilot's environment with the exact JDK version your project needs.

The Solution: copilot-setup-steps.yml

GitHub provides a special workflow file called copilot-setup-steps.yml that runs before Copilot starts working. Think of it as your project's "pre-flight checklist" for Copilot.

Create this file at .github/workflows/copilot-setup-steps.yml:

name: "Copilot Setup Steps"

on:
  workflow_dispatch:
  push:
    paths:
      - .github/workflows/copilot-setup-steps.yml
  pull_request:
    paths:
      - .github/workflows/copilot-setup-steps.yml

jobs:
  # This job name MUST be exactly "copilot-setup-steps"
  copilot-setup-steps:
    runs-on: ubuntu-latest

    permissions:
      contents: read

    steps:
      - name: Checkout code
        uses: actions/checkout@v5

      - name: Set up JDK 25
        uses: actions/setup-java@v4
        with:
          java-version: '25'
          distribution: 'temurin'
          cache: 'maven'

      - name: Verify Java version
        run: java -version

      - name: Download dependencies
        run: mvn dependency:go-offline -B

Let's break down the key parts:

1. The Job Name is Critical

jobs:
  copilot-setup-steps:  # MUST be this exact name

Copilot only recognizes the job if it's named copilot-setup-steps. Any other name will be ignored.

2. Setting Up JDK 25 with setup-java

- name: Set up JDK 25
  uses: actions/setup-java@v4
  with:
    java-version: '25'
    distribution: 'temurin'
    cache: 'maven'

The actions/setup-java action supports multiple JDK distributions:

Distribution	Vendor	Notes
`temurin`	Eclipse Adoptium	Recommended, community standard
`zulu`	Azul	Good compatibility
`corretto`	Amazon	AWS-optimized
`microsoft`	Microsoft	Azure-optimized
`oracle`	Oracle	Official Oracle JDK
`liberica`	BellSoft	Full and lite versions available

3. Caching Dependencies

cache: 'maven'

This caches your Maven dependencies between Copilot sessions, significantly speeding up subsequent runs. For Gradle projects, use cache: 'gradle'.

4. Pre-downloading Dependencies

- name: Download dependencies
  run: mvn dependency:go-offline -B

This ensures all dependencies are downloaded before Copilot starts. This is especially important if:

You have private dependencies that require authentication
Your project has many dependencies
You want faster Copilot response times

Complete Example for a Maven Project

Here's a production-ready configuration for a Java 25 Maven project:

name: "Copilot Setup Steps"

on:
  workflow_dispatch:
  push:
    paths:
      - .github/workflows/copilot-setup-steps.yml
  pull_request:
    paths:
      - .github/workflows/copilot-setup-steps.yml

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest

    permissions:
      contents: read

    steps:
      - name: Checkout code
        uses: actions/checkout@v5

      - name: Set up JDK 25
        uses: actions/setup-java@v4
        with:
          java-version: '25'
          distribution: 'temurin'
          cache: 'maven'

      - name: Verify Java version
        run: |
          java -version
          echo "JAVA_HOME=$JAVA_HOME"

      - name: Build and cache dependencies
        run: |
          mvn dependency:go-offline -B
          mvn compile -DskipTests -B

Gradle Configuration

For Gradle projects, adjust the workflow accordingly:

name: "Copilot Setup Steps"

on:
  workflow_dispatch:
  push:
    paths:
      - .github/workflows/copilot-setup-steps.yml
  pull_request:
    paths:
      - .github/workflows/copilot-setup-steps.yml

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest

    permissions:
      contents: read

    steps:
      - name: Checkout code
        uses: actions/checkout@v5

      - name: Set up JDK 25
        uses: actions/setup-java@v4
        with:
          java-version: '25'
          distribution: 'temurin'
          cache: 'gradle'

      - name: Setup Gradle
        uses: gradle/actions/setup-gradle@v4

      - name: Build and cache dependencies
        run: ./gradlew dependencies --write-locks

Handling Private Dependencies

If your project uses private Maven repositories, you'll need to configure authentication. Create secrets in the copilot environment:

Go to your repository Settings → Environments
Click the copilot environment (create it if it doesn't exist)
Add environment secrets for your credentials

Then reference them in your workflow:

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest

    permissions:
      contents: read

    steps:
      - name: Checkout code
        uses: actions/checkout@v5

      - name: Set up JDK 25
        uses: actions/setup-java@v4
        with:
          java-version: '25'
          distribution: 'temurin'
          cache: 'maven'
          server-id: private-repo
          server-username: ${{ secrets.MAVEN_USERNAME }}
          server-password: ${{ secrets.MAVEN_PASSWORD }}

      - name: Download dependencies
        run: mvn dependency:go-offline -B

Testing Your Configuration

The copilot-setup-steps.yml workflow automatically runs when you:

Push changes to the workflow file
Create a PR that modifies it
Manually trigger it from the Actions tab

This lets you validate your setup before Copilot uses it.

Tips for Java Projects

Compile the Code

Pre-compiling your code helps Copilot understand your codebase faster:

- name: Compile project
  run: mvn compile test-compile -DskipTests -B

Generate Sources

If you use code generation (Lombok processors, annotation processors, etc.):

- name: Generate sources
  run: mvn generate-sources generate-test-sources -B

Install the Project Locally

For multi-module Maven projects:

- name: Install modules
  run: mvn install -DskipTests -B

Using Larger Runners

For large Java projects, consider using larger GitHub-hosted runners:

jobs:
  copilot-setup-steps:
    runs-on: ubuntu-4-core  # More CPU and RAM
    # ... rest of configuration

Larger runners provide more resources for:

Faster dependency downloads
Quicker compilation
Running memory-intensive tests

Conclusion

By creating a copilot-setup-steps.yml workflow, you ensure that GitHub Copilot coding agent has access to the exact Java version your project needs. This eliminates build failures, speeds up Copilot's work, and provides a consistent development environment.

Key takeaways:

Create .github/workflows/copilot-setup-steps.yml with the exact job name copilot-setup-steps
Use actions/setup-java@v4 to install JDK 25 or any version you need
Enable caching for Maven or Gradle dependencies
Pre-download dependencies to speed up Copilot's work
Test your workflow by pushing changes or manually triggering it

Now Copilot can work with your Java 25 project just as effectively as it would on your local machine!

References:

Published: February 5, 2026

Copilot SDK for Java 1.0.7: Session Lifecycle Hooks and Enhanced Observability

Bruno Borges — Thu, 05 Feb 2026 22:49:26 +0000

I'm excited to announce the release of Copilot SDK for Java v1.0.7, bringing powerful new capabilities for session lifecycle management, improved observability, and comprehensive documentation. This release represents a significant step forward in feature parity with the official .NET SDK, with 54 commits adding over 5,200 lines of new functionality and tests.

What's New in 1.0.7

Session Lifecycle Hooks

The most significant addition in this release is the extended hooks system. While v1.0.6 introduced pre-tool and post-tool hooks, v1.0.7 adds three new lifecycle hooks that give you fine-grained control over session behavior:

onSessionStart

Called when a session starts (whether new or resumed), this hook lets you perform initialization, logging, or validation before the session begins processing:

var config = new SessionConfig()
    .setOnSessionStart((input, invocation) -> {
        System.out.println("Session started: " + input.getSessionId());
        // Initialize session-specific resources
        return CompletableFuture.completedFuture(
            new SessionStartHookOutput()
        );
    });

onSessionEnd

Called when a session ends, enabling cleanup operations, metrics collection, or audit logging:

.setOnSessionEnd((input, invocation) -> {
    Duration sessionDuration = calculateDuration(input);
    metricsCollector.recordSessionDuration(sessionDuration);
    return CompletableFuture.completedFuture(
        new SessionEndHookOutput()
    );
})

onUserPromptSubmitted

Called when the user submits a prompt, allowing you to enrich, validate, or transform prompts before they're processed:

.setOnUserPromptSubmitted((input, invocation) -> {
    String enrichedPrompt = addProjectContext(input.getPrompt());
    return CompletableFuture.completedFuture(
        new UserPromptSubmittedHookOutput()
            .setUpdatedPrompt(enrichedPrompt)
    );
})

These hooks open up powerful use cases including:

Security gates: Validate tool calls against allowlists before execution
Audit logging: Record all tool invocations for compliance
Result enrichment: Add metadata or transform tool outputs
Session analytics: Track session patterns and user behavior

Client-Level Lifecycle Events

Beyond session-scoped hooks, v1.0.7 introduces client-level lifecycle event subscriptions. This is particularly useful for applications managing multiple concurrent sessions:

// Subscribe to all lifecycle events
client.onLifecycle(event -> {
    System.out.println("Session " + event.getSessionId() + 
        " status: " + event.getType());
});

// Subscribe to specific event types
client.onLifecycle(SessionLifecycleEventTypes.CREATED, event -> {
    initializeSessionResources(event.getSessionId());
});

client.onLifecycle(SessionLifecycleEventTypes.DELETED, event -> {
    cleanupSessionResources(event.getSessionId());
});

Available event types include:

CREATED — A new session was created
DELETED — A session was deleted
UPDATED — Session state was updated
FOREGROUND — Session moved to foreground (TUI mode)
BACKGROUND — Session moved to background (TUI mode)

Foreground Session Control

For applications running in TUI+Server mode (copilot --ui-server), v1.0.7 adds APIs to control which session is displayed in the terminal UI:

// Get the currently displayed session
String currentSession = client.getForegroundSessionId();

// Switch the TUI to display a different session
client.setForegroundSessionId(anotherSessionId);

This enables building sophisticated multi-session orchestrators that can programmatically switch the TUI focus based on user activity or priority.

New Event Types

Two new event types enhance observability:

SessionShutdownEvent — Emitted when a session is shutting down, includes the reason and exit code:

session.on(SessionShutdownEvent.class, event -> {
    System.out.println("Session shutting down: " + 
        event.getData().getReason());
});

SkillInvokedEvent — Emitted when a skill is invoked, includes the skill name and invocation context:

session.on(SkillInvokedEvent.class, event -> {
    System.out.println("Skill invoked: " + 
        event.getData().getSkillName());
});

Extended Event Data

Several existing events now include additional fields:

Event	New Fields
`AssistantMessageEvent`	`id`, `isLastReply`, `thinkingContent`
`AssistantUsageEvent`	`outputReasoningTokens`
`SessionCompactionCompleteEvent`	`success`, `messagesRemoved`, `tokensRemoved`
`SessionErrorEvent`	Extended error context

JaCoCo Test Coverage

This release integrates JaCoCo 0.8.14 for test coverage reporting. Coverage reports are now:

Generated automatically during builds at target/site/jacoco-coverage/
Summarized in GitHub Actions workflow summaries
Uploaded as CI artifacts for detailed analysis

Documentation Improvements

We've significantly expanded the documentation:

Session Hooks Guide — Comprehensive guide covering all 5 hook types with practical examples
Events Reference — Complete documentation of all 33 event types
Advanced Usage — Enhanced with lifecycle events and foreground session control

Breaking Changes

Copilot CLI: Minimum required version updated from 0.0.400 to 0.0.404

Getting Started

Add the dependency to your pom.xml:

<dependency>
    <groupId>com.github.copilot-community-sdk</groupId>
    <artifactId>copilot-sdk-java</artifactId>
    <version>1.0.7</version>
</dependency>

Or try it instantly with JBang:

jbang https://github.com/copilot-community-sdk/copilot-sdk-java/blob/main/jbang-example.java

What's Next

We continue to track the official .NET SDK and port new features as they become available. Upcoming priorities include:

Additional MCP server integrations
Enhanced error recovery patterns
Performance optimizations for high-throughput scenarios

Contributing

The Copilot SDK for Java is a community-driven project. We welcome contributions! Check out our GitHub repository and the contributing guidelines.

Links:

Published: February 5, 2026

Running GitHub Copilot CLI Safely with Docker Sandbox

Bruno Borges — Mon, 02 Feb 2026 16:38:43 +0000

Docker just released a game-changing feature for developers who love running AI coding agents in "YOLO mode": Docker Sandboxes. If you've ever hesitated to let an AI agent run wild with full permissions on your machine, this is the solution you've been waiting for.

What is Docker Sandbox?

Docker Sandboxes provide disposable, isolated microVM environments purpose-built for coding agents. Each agent runs in a completely isolated version of your development environment. When it installs packages, modifies configurations, or deletes files, your host machine remains untouched.

This isolation enables what Docker calls "Level 4 Coding Agent Autonomy": letting agents like Claude Code, Codex CLI, GitHub Copilot CLI, Gemini CLI, and Kiro run unattended without constant permission prompts, while keeping your system safe.

Key Benefits

MicroVM-based isolation — Each agent runs inside a dedicated microVM with hypervisor-level security
Real development environment — Agents can install system packages, run services, and modify files freely
Safe Docker access — Agents can build and run Docker containers inside the sandbox, with no access to your host Docker daemon
Fast reset — If an agent goes off the rails, delete the sandbox and spin up a fresh one in seconds

Running Copilot CLI in a Docker Sandbox

Docker Sandbox works great with GitHub Copilot CLI. Here's how to get started:

Prerequisites

Docker Desktop 4.59 or later
macOS or Windows

Create a GitHub Copilot CLI Sandbox

docker sandbox create copilot ./your-project-folder -- --yolo

This creates an isolated sandbox with Copilot CLI ready to go in full autonomous, YOLO mode.

Authenticate with GitHub

Since Docker Sandbox doesn't yet pull authentication tokens from your local ~/.copilot/ folder during the sandbox creation process for Copilot, you'll need to authenticate manually once inside the sandbox.

Run the /login command inside the Copilot CLI. You'll see something like:

⠦ Waiting for authorization...

Enter one-time code: ABCD-1234 at https://github.com/login/device

Press any key to copy to clipboard and open browser...

Follow the device flow to authenticate, and you're ready to go!

Useful Commands

# List all your sandboxes
docker sandbox ls

# Access a running sandbox interactively
docker sandbox exec -it <sandbox-name> bash

# Remove a sandbox when done
docker sandbox rm <sandbox-name>

Why This Matters

Running AI coding agents with full autonomy has always been a trade-off between productivity and risk. Docker Sandboxes eliminate that trade-off by providing:

True isolation — Your host machine is completely protected
No permission fatigue — Let the agent work without interruption
Easy recovery — Something went wrong? Nuke the sandbox and start fresh

What's Next

Docker is continuing to expand Sandboxes based on developer feedback:

Linux support
MCP Gateway support
Ability to expose ports to the host and access host-exposed services
Support for additional coding agents

Get Started

Ready to let your AI coding agents run free (safely)? Check out the official documentation:

Happy coding — and let your agents loose! 🚀

Java devs: build something awesome with Copilot CLI and win big prizes

Bruno Borges — Mon, 02 Feb 2026 15:27:12 +0000

Here’s today's invitation: join the GitHub Copilot CLI Challenge and build something with Copilot right in your terminal. Visit the Challenge page for rules, FAQ, and submission template.

Why I’m excited about Copilot CLI (especially for Java)

If you write Java for a living, you already know the truth: the terminal is where we build and test; it is where feedback loops are short; and where most productivity gains come from “small wins” repeated hundreds of times.

Most Java developers use Maven or Gradle, and IDEs (especially IntelliJ) have fantastic support for both. But in practice, we still drop to the terminal quite regularly:

run a very specific Maven goal or Gradle task
we want to reproduce CI as much as possible
add flags to isolate one failing test
check output in the same environment your teammates (and CI) will see
run a single test the same way CI does, but you don’t remember the exact incantation.

If we’re already inside the terminal running commands, we might as well ask Copilot CLI to help us do the right thing faster. GitHub Copilot CLI brings an agentic workflow to the place where those loops happen: the command line. And the best part: you can keep it grounded in your repo and your actual build output.

You can also join Johannes' live stream this week on the topic!

// Detect dark theme var iframe = document.getElementById('tweet-2017976333385556316-376'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2017976333385556316&theme=dark" }

The challenge (quick overview)

The challenge is quite open-ended: build an application using GitHub Copilot CLI. But there is a judging criteria: (1) use of GitHub Copilot CLI; (2) share usability and user experience; and (3) must be original and creative!

The challenge is already up and running since January 22nd, but there is still time. The submissions are due by February 15th at 11:59 PM PST and the winners will be announced on February 26th.

This challenge comes with really cool prizes: the top 3 winners will get $1,000 USD plus a GitHub Universe 2026 ticket and a winner badge. Then, the next 25 runner-ups will get a 1-year GitHub Copilot Pro+ subscription with a runner-up badge. All valid submissions get a GitHub completion badge.

Ship a Java tool, for end-users or for developers

It can be a Spring Starter, a Quarkus Extension, a JavaFX application, a web application, Maven or Gradle plugins, a Java Swing application, plugins for IntelliJ or Eclipse, or even Apache JMeter! This is the kind of challenge where a small, well-executed tool can be more impressive than a giant “AI demo.” If you’re on the fence, here’s my recommendation:

pick a problem you hit every week
build a thin vertical slice in a day
make it pleasant to use
write a clean “how to run it” section
tell the story of how Copilot CLI helped you iterate

Need more to think on what to build?

These are Java-friendly ideas that fit the judging criteria and are designed to be realistic, shippable, and easy for judges to evaluate:

Test failure triage assistant for Maven/Gradle: parse surefire output, summarize likely causes, suggest next commands to run
Log explainer: ingest a stack trace + environment info and generate a focused explanation + remediation checklist
Repo onboarding CLI: generate a “first 30 minutes” guide for your project (build, tests, conventions, release process)
Changelog helper: read git history and propose a changelog entry + release notes draft
OpenAPI → Spring Boot starter: take an OpenAPI spec and scaffold a production-ready service layout

Prompts you can try today (copy/paste inspiration)

In your terminal (inside a repo), try asking Copilot CLI things like:

“Summarize why my Maven tests are failing from this output, then suggest the next 3 commands I should run.”
“Generate a JUnit 5 test for this class focusing on boundary cases.”
“Explain this stack trace like I’m onboarding to the project; point me to the likely source file and fix.”
“Propose a refactor that reduces duplication but keeps the public API stable.”
“Write a README section that explains how to run this tool, with examples.”

The key is to keep the agent grounded in real inputs: actual logs, actual code, actual constraints.

Programmatic control via the Copilot SDK for Java

If you want to build a Java app that programmatically drives Copilot CLI, start here:

https://github.com/copilot-community-sdk/copilot-sdk-java

More Resources

Use these to bootstrap your project fast:

Kotlin MCP development collection: https://github.com/github/awesome-copilot/blob/main/collections/kotlin-mcp-development.md
Java MCP development collection: https://github.com/github/awesome-copilot/blob/main/collections/java-mcp-development.md
Java development collection (Spring Boot, Quarkus, JUnit, Javadoc, upgrade guides): https://github.com/github/awesome-copilot/blob/main/collections/java-development.md
OpenAPI → Spring Boot application collection: https://github.com/github/awesome-copilot/blob/main/collections/openapi-to-application-java-spring-boot.md
Copilot SDK for Java: https://github.com/copilot-community-sdk/copilot-sdk-java

Ready? Here’s your next step

If you build Java tools, this challenge is a great excuse to ship something useful and learn an agentic workflow you can reuse. Join the challenge and start your submission here:

https://dev.to/challenges/github-2026-01-21

If you do build something, tag me on DEV / socials — I’d love to see what you ship.

Introducing the Copilot Community SDKs

Bruno Borges — Thu, 22 Jan 2026 21:42:54 +0000

I am excited to announce the Copilot Community SDK — a community-driven collection of SDKs for building integrations with the GitHub Copilot CLI and related Copilot tooling. This project aims to make it easier for developers to extend Copilot workflows across languages and tools not yet covered by first-party support in the official copilot-sdk repository.

What is the Copilot Community SDK?

The Copilot Community SDK is an open-source effort providing language bindings and SDKs that let developers programmatically interact with the Copilot CLI. Each SDK wraps the Copilot CLI server and exposes idiomatic APIs for your favourite languages, making it easier to build tools, plugins, and workflows that leverage Copilot’s capabilities in custom environments.

This is especially useful for tooling and extensions that need Copilot automation without embedding a lot of CLI plumbing yourself.

Spotlight: Rust Copilot SDK

Based on Rust 1.85, the Rust SDK allows developers to build apps that will interact with the GitHub Copilot CLI agent runtime through JSON-RPC over stdio or TCP.

Spotlight: Java Copilot SDK

This project already contains the Java Copilot Community SDK. Designed for JVM-based tooling and services, the Java Community SDK wraps the Copilot CLI, letting Java developers call Copilot programmatically from their apps or plugins.

With the Java Copilot Community SDK you can:

Invoke Copilot completions from Java code
Build integrations in JVM-focused tools (e.g., IDE plugins, Maven/Gradle plugins, Jenkins plugins, and more)
Combine Copilot suggestions with custom workflows

This gives you the building blocks to embed Copilot-powered features in places a CLI alone can’t reach. The SDK is available on Maven Central and can be easily embedded into Java-based tools and applications.

Example: Apache JMeter Copilot Chat Plugin

To show the Copilot Community SDK in action, let’s look at a real-world example: the Apache JMeter Copilot Chat plugin.

Apache JMeter with a Copilot Chat experience

This project brings a GitHub Copilot Chat experience directly into Apache JMeter, the popular performance and load-testing tool. Using the Copilot Community SDK as a bridge, it allows users to:

Ask Copilot questions about JMeter capabilities
Ask Copilot to trigger a load test and show results in the browser
Generate or modify JMeter test components with natural language
Get help with scripting and performance test logic without leaving the tool

🚀 Start Building and Join the GitHub Copilot CLI Challenge

If this got you thinking “I could build something cool with this”, now is the perfect time to do it.

The GitHub Copilot CLI Challenge is an open invitation to experiment, build, and ship creative integrations using Copilot. Whether you’re hacking on a weekend project, extending an existing tool, or prototyping something wild, your work can earn real rewards, including:

🎟️ GitHub Universe tickets
🤖 GitHub Copilot Pro subscriptions
🎁 And more prizes for standout projects

The Copilot Community SDK is a great foundation for challenge entries, especially if you want to go beyond simple CLI usage and embed Copilot into real tools, plugins, or workflows. Java, Rust, and other community SDKs let you meet Copilot where developers already work.

How to get started

Join the challenge and check the rules and prizes
Pick a language SDK (or help create a new one)
Build an integration, plugin, or workflow powered by Copilot
Share your project with the community

👉 Join the GitHub Copilot CLI Challenge here:

https://dev.to/devteam/join-the-github-copilot-cli-challenge-win-github-universe-tickets-copilot-pro-subscriptions-and-50af

If you build something using the Copilot Community SDK, let me know. I’ll happily try it out, share feedback, and help promote it. Let’s see how far we can push Copilot together.

Have You Ever Migrated To or From Rust? Lessons from Java Community Voices

Bruno Borges — Wed, 15 Oct 2025 04:00:00 +0000

Setting the Stage

On r/java, developer u/fenugurod started a thoughtful discussion:

I don't want to start any flame war but I'm seeking different perspectives than mine. I'm doing a career change out of Go right now into Java, because the company that I work on decided to use more Java, and it has been nice. On personal projects I was kind of doing the same, but to Rust.

I like Go's tradeoffs, but over time I'm getting disappointed with the type system that does not let me express logic with more precision. I think Rust would be a perfect language, for me, if it had a GC. The immutability by default, option and result types, enums, are really good. On the other hand, Java has an amazing GC, is getting more and more features, and now I'm wondering if Java could fill this sweet spot of development that I'm looking for. A massive point in favour of Java is the market, there are almost no positions to Rust.

This is the reason of this thread, to understand if others have migrated to or from Rust to get their perspectives. I don't care that much about performance, Rust is faster but Java is plenty. I also don't care about shiny new type system features. The core for me is immutability (optional), ADT, Option/Result types. I care about safety, simplicity, and being able to evolve the software over time.

This sparked a remarkably nuanced debate among developers who have lived in both ecosystems. The comments reveal less of a language war and more of a pragmatic conversation about safety, maintainability, and team dynamics.

Let’s unpack what the thread teaches us.

1. “Don’t ‘migrate’ — learn broadly.”

u/bowbahdoe put it best:

You as an individual should not "migrate" to anything. Learn all the things you are able to. Take the jobs that serve your interests.

Because its always fun to point out and not everyone knows, you can get ADTs similar to Rust in Java via sealed interfaces.
sealed interface Animal {
    record Dog() implements Animal {}
    record Cat(double jumpDistance) implements Animal {}
    record Mouse(boolean quiet) implements Animal {}
}

Analysis:

This perspective reflects a mature understanding of how engineers grow. Technology decisions often feel existential early in a career (“Should I be a Rust developer or a Java developer?”), but over time, the best engineers realize that breadth builds judgment.

As the commenter notes, Java continues to evolve in expressiveness—features like sealed classes, pattern matching, and records are closing the gap with Rust’s algebraic data types.

2. The Hybrid Reality: Use Both

u/repeating_bears offered a pragmatic example:

I'm currently using both. Mostly Java but my application has a native component that's written in Rust. I tried Graal initially, but it seems like it doesn't or didn't support AWT/Swing on Windows and I needed that.

There are some really good things about Rust. Other than what you mentioned, serde is great, and the type inference is much better than Java (e.g. keeping the inference context across things like chained method invocations). Macros are great a lot of the time but occasionally horrible.

But I personally am not and don't aspire to be a low-level systems programmer. I'm happy with the performance of the JVM. It's always been good enough for every real-world performance requirement I've had. I feel like a lot of the annoying aspects of Rust exist because the language designers care about things that I don't generally care about. That's not a criticism, it just doesn't really fit my programming niche.

Commentary:

This captures the “and, not or” philosophy that defines modern software stacks. Rust and Java can coexist beautifully: Rust shines where performance or memory control matter (native modules, libraries, system glue), while Java dominates in business logic, scalability, and developer productivity.

Insight:

Language boundaries are not hard walls anymore. JNI, GraalVM, and FFI make hybrid architectures practical. The best developers choose integration, not migration.

3. The Cost of Rewrites

u/lambda_lord_legacy reminded everyone:

People here are going to like java. People in the rust sub will like rust. Everyone has their preferences.

At the end of the day these are just tools. Unless you're doing something very low level, you can create all the same things in java vs rust. So it's up to you what you want to do.

Migrations have cost. You need to be REALLY sure you will benefit from it to make it worth while.

Analysis:

Rewrites are emotionally satisfying but strategically risky. Organizations often underestimate migration debt — the integration work, testing effort, and retraining required when adopting a new language.

Key takeaway:

Unless there’s a structural or existential reason (like platform support or runtime constraints), rewriting in another language rarely delivers proportional value. Optimize where it matters most, and measure impact before committing.

4. Java Is “Fast Enough”

u/SuspiciousDepth5924 added:

Honestly, even with very low level stuff you could probably get by with having most of your code in java* assuming you'd be willing to deal with FFI for the hot loops. I mean people get by with writing python for ML workloads, and it actually works since most of the heavy lifting is being done by C and friends.

And I mean Java is fast, just not quite "John Carmack optimized C" fast.

(*) Notable exception is places where you can't run a jvm in the first place like small microcontrollers etc.

Commentary:

This is a reality many forget: for 95% of applications, Java’s performance is not the bottleneck. The JVM’s JIT compiler, adaptive optimization, and garbage collection make it “fast enough” for the vast majority of workloads.

Rust shines in specialized domains—embedded, real-time, or performance-critical systems—but most businesses care more about delivery velocity and maintainability than microsecond gains.

5. Beyond Java and Rust: The JVM Ecosystem

u/Typen shared a balanced view:

I have a strong preference for Java based on my personal experience level with it, but Rust is a fine language. I know the internet likes to argue over every little thing, but I'm in the camp that likes them both.

Insight:

The modern JVM gives you more than one flavor of expressiveness. Kotlin, Scala, and Clojure all offer richer type systems or functional paradigms while keeping Java interoperability.

If what draws you to Rust is its safety and ADT-like expressiveness, you might already find 80% of that inside the JVM without leaving your ecosystem.

Key Takeaways for Professionals

Consideration	Question to Ask	Strategic Insight
Motivation clarity	Why do I want this migration?	If it’s about language aesthetics, the payoff may not justify the cost.
Ecosystem & team readiness	Can my team learn Rust? Is hiring feasible?	Rust’s talent pool is still small compared to Java’s.
Hybrid vs full rewrite	Can we adopt Rust only where it adds value?	Many organizations succeed with hybrid architectures.
Refactoring cost & risk	How much regression risk can we afford?	Rewrites introduce new bugs as fast as they remove old ones.
Maintainability	Who will maintain this five years from now?	Familiarity and tooling often outweigh elegance.
Alternative paths	Would Kotlin or Scala satisfy our needs?	Sometimes the evolution path is within the same ecosystem.
Tooling maturity	Are build, debug, and deploy pipelines ready?	Tooling gaps can outweigh language benefits.

Final Thoughts

This Reddit thread is a snapshot of something bigger: how developers mature in their thinking about tools.

Rust and Java aren’t competitors as much as they are complementary paradigms — one optimized for control and safety, the other for scalability and ecosystem depth.

The smartest developers don’t pledge allegiance. They build judgment.

When you’re faced with the “Rust vs Java” question, reframe it as:

“What problem am I solving, and which language makes my team fastest, safest, and happiest doing it?”

That’s the migration that really matters.

A Better Way to Tune the JVM in Dockerfiles and Kubernetes Manifests

Bruno Borges — Fri, 12 Sep 2025 03:36:26 +0000

When tuning the JVM inside containers, I often see Dockerfiles and Kubernetes manifests with long, hard-to-read java commands packed with -Xmx, -XX:+UseG1GC, and other flags. Every time you want to tweak memory or GC settings, you have to edit those commands and rebuild or redeploy.

Free webinar Java on Kubernetes Performance Engineering

Running Java on Kubernetes? It's harder - and more critical - than you think. Join us September 25th, 2025, for a live webinar with Akamas & Microsoft on tuning Java apps at scale. JVM tips, GC tuning, JDK 25, Project Leyden & more.

What about JAVA_OPTS?

This flag is not read by the JVM itself. It only works if the launch script explicitly uses it and expands its content into the call to the java launcher. It behaves exactly the same as Apache Tomcat's CATALINA_OPTS, which is read by catalina.sh.

There’s a much cleaner way to do this... and it’s built into the JDK. It’s the most modern, well-scoped solution, playing well with deployment orchestration solutions like Kubernetes.

🚀 Enter JDK_JAVA_OPTIONS

JDK_JAVA_OPTIONS is an environment variable that the JVM reads automatically. Whatever you put there gets appended to the command line of every JDK tool (java, javac, jshell, etc.) This means you can move all your tuning flags out of your launcher command, keeping your Dockerfiles and manifests clean and maintainable.

Cleaned-up Dockerfile

Before (messy):

CMD ["java", "-Xmx512m", "-XX:+UseG1GC", "-jar", "app.jar"]

After (clean):

ENV JDK_JAVA_OPTIONS="-Xmx512m -XX:+UseG1GC"
CMD ["java", "-jar", "app.jar"]

Now, if you need to change heap size or GC settings, you just update the environment variable. No need to touch the command.

Kubernetes Example

If your container is likely to end up on Kubernetes, don't even tune the JVM in the Dockerfile. Consider leaving this as an external configuration, coming from the Kubernetes manifest.

This is because the container image doesn't know what memory limits will be applied during runtime. And even if you set a MaxRAMPercentage for the heap, the amount you set may not be ideal if the container ends up with too much memory, potentially wasting memory from the delta not used, for example.

containers:
  - name: myapp
    image: myapp:latest
    env:
      - name: JDK_JAVA_OPTIONS
        value: "-Xmx512m -XX:+UseG1GC"

Your deployment YAML stays clean and your operations team can tune JVM behavior at deploy time without changing the image.

Why JDK_JAVA_OPTIONS Is Better

✅ Cleaner Manifests – fewer arguments to maintain
🔄 Configurable at Runtime – no rebuild required
🛠 Debug-Friendly – JVM prints the options it picked up
🐳 Perfect for Containers – works across Docker, Kubernetes, ECS, etc.
🎯 Applies to All JDK Tools – not just java, but also javac, jshell, etc.

If you’re running Java apps in Docker or Kubernetes, stop hardcoding JVM flags into your command line. Use JDK_JAVA_OPTIONS instead. It makes your images cleaner, your manifests easier to read, and your JVM tuning more flexible.

Precedence, Order of Priority, and Scope

The HotSpot JVM supports, in practice, three environment variables. And for many historical reasons we ended up in this situation.

But in what order are they processed, and where? The rule of thumb is below. Except that in JDK 8, the variable JDK_JAVA_OPTIONS is not supported.


_JAVA_OPTIONS > JDK_JAVA_OPTIONS > JAVA_TOOL_OPTIONS

Besides the order they are processed, there is also where they are processed and how this impacts what parameters are effective.

According to the bug JDK-8170832:

_JAVA_OPTIONS and JAVA_TOOL_OPTIONS environment variable are interpreted by the VM, not the launcher [java], hence no @-files or launcher-only options. The former is undocumented and unsupported but widely used; the latter is documented and supported.

You can see for yourself the behaviour of these environment variables with this little project I built (with GitHub Copilot): github.com/brunoborges/jdk-env-vars

Thoughts?

What JVM tuning tricks are you using in containers today?
Have you tried JDK_JAVA_OPTIONS yet?
Did you know about it?

Comment below.

Resources

OpenJDK 21: JAVA_TOOL_OPTIONS documentation
OpenJDK 21: JDK_JAVA_OPTIONS documentation
JDK-8170832: Add a new launcher environment variables

Announcing Azure Command Launcher for Java

Bruno Borges — Tue, 27 May 2025 23:36:41 +0000

Optimizing JVM Configuration for Azure Deployments

Tuning the Java Virtual Machine (JVM) for cloud deployments is notoriously challenging. Over 30% of developers tend to deploy Java workloads with no JVM configuration at all, therefore relying on the default settings of the HotSpot JVM.

The default settings in OpenJDK are intentionally conservative, designed to work across a wide range of environments and scenarios. However, these defaults often lead to suboptimal resource utilization in cloud-based deployments, where memory and CPU tend to be dedicated for application workloads (use of containers and VMs) but still require intelligent management to maximize efficiency and cost-effectiveness.

To address this, we are excited to introduce jaz, a new JVM launcher optimized specifically for Azure. jaz provides better default ergonomics for Java applications running in containers and virtual machines, ensuring a more efficient use of resources right from the start, and leverages advanced JVM features automatically, such as AppCDS and in the future, Project Leyden.

Why jaz?

Conservative Defaults Lead to Underutilization of Resources

When deploying Java applications to the cloud, developers often need to fine-tune JVM parameters such as heap size, garbage collection strategies, and other tuning configurations to achieve better resource utilization and potentially higher performance. The default OpenJDK settings, while safe, do not take full advantage of available resources in cloud environments, leading to unnecessary waste and increased operational costs.

While advancements in dynamic heap sizing are underway by Oracle, Google, and Microsoft, they are still in development and will be available primarily in future major releases of OpenJDK. In the meantime, developers running applications on current and older JDK versions (such as OpenJDK 8, 11, 17, and 21) still need to optimize their configurations manually or rely on external tools like Paketo Buildpacks, which automate tuning but may not be suitable for all use cases.

With jaz, we are providing a smarter starting point for Java applications on Azure, with default configurations designed for cloud environments. The jaz launcher helps by:

Optimizing resource utilization: By setting JVM parameters tailored for cloud deployments, jaz reduces wasted memory and CPU cycles.
Improve first-deploy performance: New applications often require trial and error to find the right JVM settings. jaz increases the likelihood of better performance on first deployment.
Enhance cost efficiency: By making better use of available resources, applications using jaz can reduce unnecessary cloud costs.

This tool is ideal for developers who:

Want better JVM defaults without diving deep into tuning guides
Develop and deploy cloud native microservices with Spring Boot, Quarkus, or Micronaut
Prefer container-based workflows such as Kubernetes and OpenShift
Deploy Java workloads on Azure Container Apps, Azure Kubernetes Service, Azure Red Hat OpenShift, or Azure VMs

How jaz works?

jaz sits between your container startup command and the JVM. It will:

Detect the cloud environment (e.g., container limits, available memory)
Analyzes the workload type and selects best-fit JVM options
Launches the Java process with optimized flags, such as:
- Heap sizing
- GC selection and tuning
- Logging and diagnostics settings as needed

Example Usage

Instead of this:

$ JAVA_OPTS="-XX:... several JVM tuning flags"
$ java $JAVA_OPTS -jar myapp.jar"

Use:



$ jaz -jar myapp.jar

You will automatically benefit from:

 * Battle-tested defaults for cloud native and container workloads
 * Reduced memory waste
 * Better startup and warmup performance
 * No manual tuning required

## How to Access jaz (Private Preview)

jaz is currently available through a Private Preview. During this phase, we are working closely with selected customers to refine the experience and gather feedback.

To request access:

👉 [Submit your interest here](https://aka.ms/jaz-privatepreview)

Participants in the Private Preview will receive access to jaz via easily installed standalone Linux packages for container images of the Microsoft Build of OpenJDK and Eclipse Temurin (for Java 8). Customers will have direct communication with our engineering and product teams to further enhance the tool to fit their needs. For a sneak peek, you can read the [documentation](http://learn.microsoft.com/java/jaz/overview).

## Our Roadmap

Our long-term vision for `jaz` includes adaptive JVM configuration based on telemetry and usage patterns, helping developers achieve optimal performance across all Azure services.

⚙️ JVM Configuration Profiles
📦 AppCDS Support
📦 Leyden Support
🔄 Continuous Tuning
📊 Share telemetry through Prometheus

We’re excited to work with the Java community to shape this tool. Your feedback will be critical in helping us deliver a smarter, cloud-native Java runtime experience on Azure.

Java 15 in 2020: Reasons to not use Java?

Bruno Borges — Wed, 27 May 2020 01:52:28 +0000

In 2020, Java 15 will be released with major features (some coming out of preview mode), both at language, API, and runtime levels.

https://openjdk.java.net/projects/jdk/15/

Considering the changes that have already made through since Java 8 and the upcoming changes in Java 15, what are in your opinion the use cases that no longer make sense to use Java, and why?

DEV Community: Bruno Borges

How I Automated Weekly Twitter/X Posts With GitHub Actions

The Problem

The Architecture

Component 1: The Queue & Tweet Generator

Handling New Patterns

Component 2: The Post Script

OAuth 1.0a in Java

Component 3: The GitHub Actions Workflow

The Economics

Built in a Single Copilot CLI Session

What I'd Do Differently

Try It Yourself

Translating a Website into 8 Languages with AI Agents in One Night

How I used Claude Sonnet 4.6 and fleets of GitHub Copilot Coding Agents to internationalize java.evolved — from spec to deployment

The Architecture Decision: Let the AI Draft the Spec

Phase 1: Building the Infrastructure

Phase 2: The First Translations (Spanish + Portuguese)

Phase 3: The Fleet — 6 Languages in Parallel

The Numbers

The Arabic Surprise: RTL Support

The One Bug

Why It Worked: Architecture as Force Multiplier

1. Source of Truth Separation

2. Partial File Fallback

3. Convention Over Configuration

Lessons Learned

What Went Well

What Required Human Intervention

The Timeline

Conclusion

Enabling AI Agents to Use a Real Debugger Instead of Logging

The JDK ships a perfectly good debugger. Nobody uses it.

Agent Skills: Teaching new tricks through Markdown

Building the skill: a conversation with Copilot

What the skill contains

The real test: debugging a buggy Swing app, live

The debugging session

A small but important lesson: compile with -g

Why this matters

Beyond println debugging

Interactive debugging as a first-class agent capability

The shift from static analysis to dynamic observation

Try it yourself

What's next

How to Configure JDK 25 for GitHub Copilot Coding Agent

The Problem

The Solution: copilot-setup-steps.yml

1. The Job Name is Critical

2. Setting Up JDK 25 with setup-java

3. Caching Dependencies

4. Pre-downloading Dependencies

Complete Example for a Maven Project

Gradle Configuration

Handling Private Dependencies

Testing Your Configuration

Tips for Java Projects

Compile the Code

Generate Sources

Install the Project Locally

Using Larger Runners

Conclusion

Copilot SDK for Java 1.0.7: Session Lifecycle Hooks and Enhanced Observability

What's New in 1.0.7

Session Lifecycle Hooks

onSessionStart

onSessionEnd

onUserPromptSubmitted

Client-Level Lifecycle Events

Foreground Session Control

New Event Types

Extended Event Data

JaCoCo Test Coverage

Documentation Improvements

Breaking Changes

Getting Started

What's Next

Contributing

Running GitHub Copilot CLI Safely with Docker Sandbox

What is Docker Sandbox?

A small but important lesson: compile with `-g`

Beyond `println` debugging

Java 15 in 2020: Reasons to not use Java?