KotlinLLM, a research prototype for delegating runtime logic to a large language model (LLM) from Kotlin code, is now going open source and public, JetBrains announced.

Revealed July 28, KotlinLLM is an IntelliJ IDEA plugin prototype for experimenting with LLM-driven “Smart macros” in Kotlin, enabling code generation, runtime updates, and hot-reloading. In software engineering, LLMs are commonly used during development for code completion, code generation, and program comprehension, JetBrains noted, but using an LLM at run time of a compiled application is much less common. The existing options for doing this have the following trade-offs, according to JetBrains:

• Direct runtime delegation is slow, non-deterministic, and costly, and makes the application depend on an LLM service at run time.
• External agent workflows keep the generated logic outside the codebase, where it is harder to review, test, and ship.
• Most prior work (byLLM, nightjar, Healer) targets interpreted languages like Python, not a compiled, statically typed language like Kotlin.

KotlinLLM addresses these limitations in three ways, JetBrains said:

• The call site shows that a feature is LLM-backed, so it is visible in code review.
• Generated behavior is saved as an ordinary Kotlin source, not kept only in the runtime session. It can be committed, reviewed, tested, and distributed like any other code.
• Once generated, the code runs as plain Kotlin without the plugin. For scenarios that are already covered, there is no further LLM call, so no added latency or cost, and the result is reproducible.

KotlinLLM is open source under Apache License 2.0. The repository contains the KotlinLLM IntelliJ IDEA plugin, the Smart macro API, and example projects.

Microsoft has released MCP C# SDK v2.0, a major update of the company’s official C# SDK for Model Context Protocol (MCP) servers and clients.

Unveiled July 28, MCP C# SDK v2.0 implements the 2026-07-28 revision of the MCP specification, which Microsoft described as the protocol’s largest revision since its launch. The 2026-07-28 revision makes the MCP protocol stateless by default, standardizes the HTTP surface to allow ordinary HTTP infrastructure to route MCP traffic, and introduces Multi Round-Trip Requests (MRTR) to support interaction without requiring long-lived sessions.

MCP C# SDK 2.0 moves in lockstep with these changes, Microsoft said. The HTTP server transport now runs statelessly by default. Whereas version 1.x of the SDK configured stateful sessions out of the box, in version 2.0 HttpServerTransportOptions.Stateless defaults to true.

MCP C# SDK v2.0 also implements a small set of HTTP headers that the 2026-07-28 MCP revision standardizes. A tools/call now includes Mcp-Method: tools/call and Mcp-Name: get_order_status alongside the JSON-RPC body. With the 2026-07-28 revision, an MCP request becomes a single, self-describing HTTP POST. This means that ordinary HTTP infrastructure such as load balancers, proxies, gateways, and web application firewalls now can act on MCP traffic without deep packet inspection, Microsoft said.

And MCP C# SDK 2.0 adds support for MRTR on the server and on the client. MRTR addresses scenarios in which tools can’t answer in a single round trip, such as when a server wants to confirm with a user before taking a significant action. In previous versions of MCP, these interactions worked only over a live, stateful session. With MRTR, they work with no session at all, because all the continuity travels in the payload, Microsoft said.

With the 2026-07-28 spec compliance landing in MCP C# SDK 2.0, Microsoft said the SDK’s next focus is end-to-end authentication and authorization. The goal is to make secure MCP deployments as “turnkey” as the rest of the stack, building on the closer OAuth and OpenID Connect alignment the spec introduced, Microsoft said. 

Java Development Kit 27, an Oracle-driven, planned update to standard Java, is set to reach its initial release candidate (RC) stage on August 6. This update has features ranging from making the Garbage-First (G1) garbage collector the default collector and adding structured concurrency to simplify concurrent programming. JDK 27 is currently in rampdown phase 2, with the feature set now frozen.

Overall, there are nine features listed on what is described as a reference implementation of JDK 27. The first five features include making G1 the default garbage collector, post-quantum hybrid key exchange for TLS 1.3, lazy constants, structured concurrency, and primitive types in patterns, instanceof, and switch. The next four include compact object headers, JFR (JDK Flight Recorder) in-process data redaction, a vector API, and PEM (Privacy-Enhanced Mail) encodings for cryptographic objects.

The final release candidate stage for JDK 27 follows on August 20, with general availability scheduled for September 15. Early-access builds for JDK 27 can be found at jdk.java.net.

With JDK 27, G1 becomes the default garbage collector in all environments, rather than just in server environments. Goals are to ensure that the HotSpot JVM will always select G1 and that performance including throughput, latency, memory footprint, and startup time does not degrade significantly.

With post-quantum hybrid key exchange for TLS 1.3, the goal is to enhance the security of Java applications that require secure network communication by implementing hybrid key exchange algorithms. Such algorithms defend against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional algorithm.

Lazy constants introduces an API for objects that hold unmodifiable data. Lazy constants are treated as true constants by the JVM, enabling the same performance optimizations that are enabled by declaring a field final. Compared to final fields, however, lazy constants offer greater flexibility in the timing of their initialization. This feature is in a third preview.

The goal of primitive types in patterns, instanceof, and switch is to enhance pattern matching by allowing primitive types in all pattern contexts, and to extend instanceof and switch to work with all primitive types. This feature is in a fifth preview.

Structured concurrency simplifies concurrent programming by introducing an API that treats groups of related tasks running in different threads as single units of work. Goals include streamlining error handling and cancellation, improving reliability, and enhancing observability. Structured concurrency is in its seventh preview.

JDK 27 makes compact object headers the default object header layout in the HotSpot JVM. Compact object headers reduce object headers from 96 bits down to 64 bits on 64-bit architectures, reducing heap size, improving deployment density, and increasing data locality.

JFR data in-process redaction allows users to redact command-line arguments and the initial values of environment variables and system properties in JFR recordings. JFR recording files may contain events that include sensitive data, such as secrets in command-line arguments, access tokens in environment variables, and passwords in system properties. This data is (optionally) redacted before it leaves the process, so that sensitive information does not leak.

The vector API introduces an API to express vector computations that reliably compile at run time to optimal vector instructions on supported CPUs, thus achieving better performance than equivalent scalar computations. This is an incubating API in its 12th incubation.

PEM encodings of cryptographic objects introduces an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists in the PEM transport format, and for decoding from PEM back into objects. This is a preview API.

JDK 27 is a short-term feature release (non-LTS) that will receive six months of support from Oracle. Its predecessor, JDK 26, also a short-term release, became generally available on March 17.

For a programming language that is prized for being convenient and easy, Python has some surprising barbs and sharp edges. Find out how a new pip flag can make it easier to work with project dependencies apart from the project itself. Get the skinny on why standalone Python programs are hard to assemble, and what you can do about it. See how Python’s new Installation Manager for Microsoft Windows lets multiple versions coexist on the same system. And find out what will be shipped when Python 3.15 debuts later this year.

Top picks for Python readers on InfoWorld

New pip flag fixes longstanding Python frustration
A longstanding gripe with Python’s pip package manager has a happy ending. The next version of pip will let you install a package’s requirements without installing the package itself.

Why it’s so hard to create stand-alone Python apps
Python’s best features, its dynamism and flexibility, have a downside: They make it tough to package Python apps as standalone programs. Not impossible, though; just … complicated.

The best new features in Python 3.15
If you haven’t grabbed the beta release of Python 3.15 yet, it’s ready when you are. Here’s a rundown of all the best bits you can start using right away.

Get started with the new Python Installation Manager
This all-in-one Python version management tool is now the recommended, default way to set up and manage Python versions on Microsoft Windows — including betas, release versions, and the special JIT and free-threaded builds, too.

More good reads and Python updates elsewhere

Ruff linter gets a massive upgrade in version 0.16
The speedy, Rust-powered linter and formatter for Python now supports over 400 rules by default, making for a more useful, zero-configuration, out-of-the-box linting experience.

What every Python developer should know about the CPython ABI
A massive, multilayered unpacking of that most intimidating of Python internals, the CPython application binary interface. Even if you never plan to write a CPython extension or contribute to the CPython project, the details laid out here are eye-opening.

Free-threaded Python: past, present, and future
At PyCon 2026, CPython core developer Thomas Wouters gave a talk about how Python came to support threads via the GIL, and how its developers went about removing the GIL over many years and multiple attempts. Excellent recap available at LWN.net.

PEP 837: Extensible JSON serialization
A newly introduced Python Enhancement Proposal (intended for Python 3.16) to make Python’s native JSON serialization more extensible, for instance to allow new types to automatically support serialization via a __json__ method.