Editorial: Today’s trio illustrates a recurring pattern: tooling and funding decisions look small until they shape who gets control, who bears risk, and how engineers build. We’ve got a customer-facing ethics dustup, a pragmatic look at Model Context Protocol in production, and a neat engineering workaround that gives older Java apps virtual-thread–like behavior.
In Brief
1Password Replied to My Disappointment
Why this matters now: 1Password’s corporate patronage of the Omacom Foundation has prompted customer concerns that corporate donations may support people or projects with controversial views, raising questions about trust and transparency for password manager users.
A 1Password customer wrote a public note of disappointment after the company became a patron of the Omacom Foundation. 1Password replied that the donation was intended to “support hosting infrastructure and provide stable, long-term funding” for upstream open-source projects and that the contribution is “made to the Omacom Foundation, not to an individual, and is not an endorsement of any individual’s personal or political views.”
“Our contribution is made to the Omacom Foundation, not to an individual, and is not an endorsement of any individual’s personal or political views.” — 1Password
The reaction on Hacker News split between readers who found 1Password’s statement reasonable and those who want companies to be explicit about who benefits from donations. The practical takeaway is simple: customers worried about where their fees go can switch vendors, but the broader debate — whether corporate funding can be neatly separated from the politics of maintainers — is unlikely to quiet down.
Ask HN: Who is using MCP in production?
Why this matters now: Engineers integrating LLMs into workflows are increasingly evaluating Model Context Protocol (MCP) as a way to give agents controlled, discoverable access to live systems—some teams are already shipping it.
An Ask HN thread collects real-world examples of folks running MCP servers in production, describing everything from Jira- and Figma-connected agents that file and dedupe bug reports to a UK planning-scraper exposing a debug surface via MCP. Commenters note concrete advantages: standardized discovery of tools and fine-grained control over what a model can access.
“In general the advantage of MCP would be the possibility for a fine grained control over the tools the agent is allowed to use.” — comment in the HN thread
At the same time the thread is candid about pain points: poorly implemented MCP servers become operational liabilities, secret management is tricky, and for heavy text workloads a thin API client plus temporary files can be cheaper and faster. The overall tone: MCP is useful and production-worthy for targeted integrations, but it’s not a universal answer — design and ops matter.
Deep Dive
Virtual Threads for a scripting language in Java 8 without Loom
Why this matters now: Java shops stuck on older JVMs can get many of Loom’s ergonomic wins—nonblocking, blocking-style scripts and checkpointable continuations—without upgrading, which can materially lower complexity for reactive services that embed scripting.
Jactl is a tiny embeddable scripting language that aims to give older JVMs virtual-thread–like semantics by serializing script execution into a chain of continuation objects. The technique is clever and pragmatic: instead of trying to snapshot the JVM call stack (impossible on Java 8/11), the Jactl compiler rewrites script frames so that each frame catches a special Continuation exception, records locals and a resume point, and rethrows. That yields a chain of lightweight continuation records that the runtime can later walk to resume execution.
“The goal was only to save the execution state of the Jactl code, not the state of the Java code that was invoking a Jactl script.” — from the Jactl post
Operationally that unlocks two valuable features. First, embedding a blocking-style script into an event-loop system no longer requires blocking the event thread: the script can suspend and be resumed when I/O completes. Second, the continuation chain is serializable — the author demonstrates checkpointing continuations to disk for redundancy, so long-running scripts can survive process restarts or be migrated. For teams that need durable workflows (think long-running webhooks, user-driven background jobs, or scheduled tasks) this reduces the need for bespoke orchestration.
There are performance trade-offs, of course. The author includes a JMH benchmark showing modest overhead for suspend/resume in nested stacks and points out a key trick: throwing an exception that doesn’t fill in a stack trace is much cheaper than a full exception. Jactl also acknowledges precedent — Apache Javaflow and other bytecode-instrumentation projects have explored continuations before — but Jactl packages the approach into a small, embeddable scripting surface that you can disable when running on modern JVMs that support Loom’s real virtual threads.
What this means in practice: teams can get Loom-like ergonomics without the migration or runtime upgrade, but they must accept a compiler+runtime rewrite of the script boundary and the operational surface of serialized continuations. That’s a reasonable trade for many legacy reactive apps where changing the JVM or rewriting thread models would be more expensive than adding a small sandboxed scripting engine.
Bold takeaway: Jactl offers a practical middle path—Loom-style developer ergonomics and checkpointing for teams that can’t yet move to a modern JVM, at the cost of a compiler-driven continuation model and the usual operational vigilance.
Closing Thought
Open-source funding, model integration, and runtime ergonomics all expose the same fault line: small infrastructure choices—who you pay, how you expose tools to an LLM, or how you emulate threads—compound into governance, security, and maintenance trade-offs. Today’s stories are a reminder that engineers should treat those choices as public-facing design decisions: they affect trust, risk, and the levers your team can pull later.