Share via

Microsoft Technical Support Request: Java NIO Selector Compatibility in MSIX Packages

Jude Park 5 Reputation points
2025-10-27T15:46:38.74+00:00

Date: Oct 24, 2025
Technology Stack: Kotlin Compose Desktop, Java 21, jpackage
Issue Category: MSIX Packaging, Network Isolation, Java NIO Compatibility

Executive Summary

We are developing a desktop application using Kotlin Compose Multiplatform and packaging it for the Microsoft Store using MSIX. The application works perfectly as a standard MSI package but fails to start in MSIX due to Java NIO Selector initialization errors. We need clarification on whether Java-based applications that use NIO Selectors are fundamentally incompatible with MSIX, or if there is a supported way to enable this functionality.

Application Overview

Application Purpose:

  • Desktop tool that bridges Figma design files with Cursor AI IDE
  • Provides real-time synchronization via WebSocket connections
  • Handles OAuth 2.0 authentication flows with local callback server

Core Functionality:

  1. WebSocket Server (127.0.0.1:3055) - Receives connections from Figma plugin
  2. HTTP Server (127.0.0.1:3056) - MCP (Model Context Protocol) server
  3. OAuth Callback Server (127.0.0.1:8080) - Receives OAuth redirects from browser
  4. HTTP Client - Communicates with external Figma REST API

Current Packaging:

  • MSI via jpackage: ✅ Works perfectly
  • MSIX with PSF: ❌ Fails with NIO Selector errors

Technical Problem

Error Description

When the application is packaged as MSIX and installed, it crashes immediately with the following error:

java.io.UncheckedIOException: java.io.IOException: Unable to establish loopback connection

at java.net.http/jdk.internal.net.http.HttpClientImpl.\<init\>(Unknown Source)

at java.net.http/jdk.internal.net.http.HttpClientImpl.create(Unknown Source)

at java.net.http/jdk.internal.net.http.HttpClientBuilderImpl.build(Unknown Source)

Caused by: java.io.IOException: Unable to establish loopback connection

at java.base/sun.nio.ch.PipeImpl$Initializer.run(Unknown Source)

at java.base/sun.nio.ch.PipeImpl.\<init\>(Unknown Source)

at java.base/sun.nio.ch.WEPollSelectorImpl.\<init\>(Unknown Source)

at java.base/sun.nio.ch.WEPollSelectorProvider.openSelector(Unknown Source)

Caused by: java.net.SocketException: Invalid argument: connect

at java.base/sun.nio.ch.UnixDomainSockets.connect0(Native Method)

at java.base/sun.nio.ch.UnixDomainSockets.connect(Unknown Source)

at java.base/sun.nio.ch.SocketChannelImpl.connect(Unknown Source)

Root Cause Analysis

The error occurs during Java NIO Selector initialization, specifically when PipeImpl attempts to create an internal pipe using Unix Domain Sockets for inter-thread communication. This is a fundamental JVM operation that happens when:

  1. java.net.http.HttpClient is instantiated
  2. java.nio.channels.Selector.open() is called
  3. com.sun.net.httpserver.HttpServer.create() is called
  4. Any NIO-based networking library (Ktor CIO, Java-WebSocket) starts

Affected Components

Component Library Purpose Status in MSIX
HTTP Client java.net.http.HttpClient External API calls ❌ Fails
WebSocket Server org.java-websocket Figma plugin communication ❌ Fails
MCP Server Ktor CIO Engine AI IDE integration ❌ Fails
OAuth Server com.sun.net.httpserver.HttpServer OAuth callbacks ❌ Fails

What We've Already Tried

We have already configured the MSIX package with:

  1. ✅ All necessary capabilities:
    • runFullTrust
    • internetClient, internetClientServer, privateNetworkClientServer
  2. ✅ Loopback exemption enabled via CheckNetIsolation.exe
  3. ✅ Package Support Framework (PSF) configured correctly
  4. ✅ JVM arguments attempted:
    • -Djava.net.preferIPv4Stack=true
    • -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider

Result: Despite all configuration attempts, Java NIO Selector still fails to initialize in the MSIX AppContainer. The error occurs at the native method level (sun.nio.ch.UnixDomainSockets.connect0).

Key Questions for Microsoft Support

1. Is Java NIO Selector blocked in MSIX AppContainer?

The error occurs at sun.nio.ch.UnixDomainSockets.connect0(Native Method) during NIO Selector initialization.

Question: Does MSIX AppContainer block Unix Domain Socket creation for internal JVM operations? If yes, is there a capability or workaround to enable it?

Our app requires local servers (WebSocket, HTTP, OAuth callback) which all fail due to NIO Selector.

Options we're considering:

  • A: Rewrite with traditional Blocking I/O (java.net.ServerSocket)
  • B: Switch to Netty or other networking stack
  • C: Distribute MSI instead of MSIX via Partner Center

Question: What does Microsoft recommend for Java desktop applications that need local server functionality?

3. Can we distribute MSI through Microsoft Store?

If MSIX is not viable for Java NIO applications:

Question: Does Microsoft Partner Center support MSI submission for Win32 desktop applications? If so, what are the requirements?

Technical Environment

Development Environment

  • OS: Windows 11 Pro (Build 26200)
  • Java: Amazon Corretto 21.0.1 (bundled)
  • Kotlin: 2.1.0
  • Gradle: 8.x
  • jpackage: 21.0.1
  • Windows SDK: 10.0.26100.0

Key Dependencies

dependencies {

// Networking (all use NIO Selector)

implementation("org.java-websocket:Java-WebSocket:1.5.3")

implementation("io.ktor:ktor-server-core:3.0.2")

implementation("io.ktor:ktor-server-cio:3.0.2")

implementation("io.ktor:ktor-server-websockets:3.0.2")
```​    

```scala
// UI

implementation(compose.desktop.currentOs)

implementation(compose.material3)
```}

---

## **Error Displayed in Console:**

ERROR: java.io.IOException: Unable to establish loopback connection

```scala
at java.base/sun.nio.ch.PipeImpl$Initializer.run

at java.base/sun.nio.ch.WEPollSelectorImpl.\<init\>

Caused by: java.net.SocketException: Invalid argument: connect

at java.base/sun.nio.ch.UnixDomainSockets.connect0(Native Method)

Root Cause

Java NIO Selector attempts to create an internal pipe using Unix Domain Sockets during initialization. This operation succeeds in:

  • ✅ Standard Win32 environment (MSI)
  • ✅ Regular Java applications

But fails in MSIX AppContainer at the native method level:

  • ❌ sun.nio.ch.UnixDomainSockets.connect0(Native Method)

This is a fundamental JVM operation that occurs when:

  • Creating java.nio.channels.Selector
  • Initializing java.net.http.HttpClient
  • Starting com.sun.net.httpserver.HttpServer
  • Using any NIO-based networking library

Files to Provide

We will share two packages via OneDrive/Azure Blob:

  1. MSI Package - MCP Magic-1.0.9.msi (~135 MB) - ✅ Works
  2. MSIX Package - MCPMagic-1.0.9.0.msix (~137 MB) - ❌ Crashes

How to Reproduce:

  1. Install and run MSI → Works perfectly
  2. Install and run MSIX → Console shows NIO Selector error immediately
  3. Open app's System Tray → View Logs for detailed logs

That's all you need. The issue is immediately visible.

Error 1: HttpClient Initialization

java.io.UncheckedIOException: java.io.IOException: Unable to establish loopback connection

at java.net.http/jdk.internal.net.http.HttpClientImpl.\<init\>
```Caused by: java.net.SocketException: Invalid argument: connect

```yaml
at java.base/sun.nio.ch.UnixDomainSockets.connect0(Native Method)
```### **Error 2: Ktor CIO Server**

java.io.IOException: Unable to establish loopback connection

```sql
at java.base/sun.nio.ch.PipeImpl$Initializer.run

at io.ktor.network.selector.ActorSelectorManager$1.invokeSuspend
```### **Error 3: HttpServer Creation**

java.io.IOException: Unable to establish loopback connection

```powershell
at java.base/sun.nio.ch.WindowsSelectorImpl.\<init\>

at jdk.httpserver/sun.net.httpserver.ServerImpl.\<init\>

at jdk.httpserver/com.sun.net.httpserver.HttpServer.create
```All three errors share the same root cause: `sun.nio.ch.UnixDomainSockets.connect0(Native Method)` failure.

---

## **Thank You**

We appreciate Microsoft's time and expertise in reviewing this issue. A clear answer on Java NIO compatibility with MSIX will help not only our project but the broader Java desktop application community targeting the Microsoft Store.

If this is a fundamental limitation, we understand and will explore alternatives. If there's a solution we've missed, we're eager to implement it.
Windows development | Windows API - Win32
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jack Dang (WICLOUD CORPORATION) 8,220 Reputation points Microsoft External Staff Moderator
    2025-10-28T08:27:50.76+00:00

    Hello @Jude Park - and thanks for providing such a detailed description.

    When you package your desktop Java (Kotlin Compose) application as an MSIX and run it, the JVM (and libraries) attempt to use Java NIO’s selector mechanism. Internally, on Windows, the default selector provider may use internal “pipe” or “socketpair” type constructs (in your case sun.nio.ch.UnixDomainSockets.connect0) for inter-thread/async operations.

    Under a normal Win32 environment (MSI) that works fine. However, when installed as an MSIX and executed inside an AppContainer sandbox, certain operations may be restricted or behave differently — in particular loopback, local socket creation, or Unix domain socket semantics.

    Because the stack fails at the native method connect0 with “Invalid argument: connect”, it strongly suggests the AppContainer environment is disallowing or altering behavior of internal Unix domain socket creation.

    According to Microsoft’s documentation:

    “An AppContainer app’s process and its child processes run inside a lightweight app container where they can access only the resources that are specifically granted to them.”

    and

    “Network isolation: Isolating the application from network resources beyond those specifically allocated, AppContainer prevents the application from escaping its environment.”

    Unfortunately, Microsoft does not publish any explicit guarantee that Java NIO selectors or Unix-domain sockets are fully supported under MSIX AppContainer contexts. There are known restrictions on loopback, named pipes, and UWP-style network access.

    “Network drop events from the AppContainer loopback block filter origin occur when localhost loopback isn’t enabled properly for the Universal Windows Platform (UWP) app.”

    So it appears your JVM’s default selector provider is using a native path that the sandbox blocks.

    Given your scenario (desktop app needing local WebSocket, HTTP, or OAuth callback servers on localhost), here are some approaches:

    1. Switch selector provider or forced fallback

    Provide the JVM argument:

    -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.WindowsSelectorProvider

    You mentioned trying this — make sure it’s actually taking effect (log SelectorProvider.provider() at runtime). Alternatively, consider forcing a simpler selector implementation (e.g. NIO select/poll) instead of one relying on Unix domain sockets. You may also patch or override libraries like Ktor CIO or Java-WebSocket to use plain TCP/IP (127.0.0.1) rather than Unix domain sockets.

    2. Use blocking I/O instead of NIO

    If your local server doesn’t need high-throughput async, consider refactoring to java.net.ServerSocket / Socket or a blocking I/O library. That can bypass the NIO selector path that triggers the sandbox restriction.

    3. Use a networking stack known to be MSIX-compatible

    Pick a library that explicitly works under AppContainer conditions and uses normal loopback TCP/IP. Confirm in documentation that it doesn’t rely on native Unix domain sockets or shared-memory pipes.

    Also ensure you declare the proper network capabilities in your manifest:

    “The three networking capabilities are internetClient, internetClientServer, and privateNetworkClientServer.”

    4. Consider distributing via MSI (non-AppContainer)

    If you determine that MSIX AppContainer imposes hard limitations on your networking model and refactoring is too costly, you can deliver the app via MSI with full trust (no sandbox).

    Microsoft Store primarily supports Win32 desktop apps via MSIX (“Desktop Bridge”), but MSI distribution is still possible outside the Store. Consult official Store guidance or Partner Center support for confirmation.

    “You can declare your packaged desktop app’s uap10:TrustLevel as appContainer (sandboxed) or mediumIL (full-trust).”

    What I’d recommend next

    1. Create a minimal Java test (e.g. Selector.open(), HttpClient.newHttpClient(), and a loopback socket) inside your MSIX-packaged app to confirm which SelectorProvider is active and capture any stack traces.
    2. If the provider defaults to Unix domain sockets, retry with WindowsSelectorProvider.
    3. Evaluate how much effort it would take to switch your local servers to use TCP loopback instead of NIO/Unix domain sockets.
    4. If that’s not practical, explore packaging as full-trust (runFullTrust) or fallback to MSI distribution.
    5. When following up with Microsoft Support, include:
      • SelectorProvider info and stack trace
      • AppContainer trust level
      • Network capabilities declared in manifest

    This will help confirm whether AppContainer restrictions on Unix domain sockets apply broadly to Java apps or only to your setup.

    Answers to your three questions

    1. Is Java NIO Selector blocked in MSIX AppContainer? Some internal NIO operations (especially Unix domain socket usage) appear to fail inside the AppContainer. Microsoft documentation confirms that AppContainer isolates both filesystem and network access, and loopback requires explicit enablement. (MSIX AppContainer apps) (Filter origin documentation
    2. What’s the recommended approach for Java desktop apps needing local servers? Use plain TCP/IP loopback (127.0.0.1) with blocking I/O or a compatible async library. Package with runFullTrust if the app requires local network access, and avoid Unix domain sockets or selector providers restricted by AppContainer isolation. (AppContainer isolation)
    3. Can you distribute MSI through Microsoft Store? Win32 desktop apps are primarily accepted through MSIX packaging. Pure MSI submissions are not directly supported for Store listing, but you can distribute MSI installers outside the Store. (How packaged desktop apps run on Windows)

    Hope this helps! If my answer was useful, please follow the instructions here so others with the same problem can benefit as well.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.