# Eclipse Milo for Java OPC UA development

> Eclipse Milo is an open source Java implementation of OPC UA, currently targeting version 1.05. It provides stack components, a client SDK, a server SDK, examples, and documentation for building interoperable industrial automation applications.

**eclipse-milo/milo** —  Eclipse Milo™ - an open source implementation of OPC UA (IEC 62541).

- Repository: https://github.com/eclipse-milo/milo
- Website: http://www.eclipse.org/milo
- Stars: 1,399 · Forks: 479
- Language: Java
- License: EPL-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/eclipse-milo-milo

## Milo's OPC UA scope and intended users

Eclipse Milo addresses the need to implement OPC UA, the open industrial communication standard identified by the repository as IEC 62541. Its current target is OPC UA 1.05. The project is aimed at Java developers who need to connect applications to OPC UA servers, expose services through an OPC UA server, or work with lower-level protocol components. That makes it relevant to industrial automation software, IoT integrations, gateways, and test or demonstration programs, although the README does not define a narrower industry profile.

Milo is more than a client library. The repository describes a high-performance stack covering channels, serialization, data structures, and security, with client and server SDKs built on that stack. The source layout reflects this division through `opc-ua-stack/` and `opc-ua-sdk/`, while `milo-examples/` contains runnable example programs. A Java engineer can therefore choose an SDK or work with the stack when an application needs more control over protocol behavior.

The project is open source under EPL-2.0. The README also identifies an Eclipse Milo Wiki as the user guide and directs new users to Getting Started, First Server, First Client, and the client and server guides. This documentation-first structure is useful for a protocol SDK, because the repository itself primarily explains the available modules and build route rather than reproducing the complete application workflow.

## Inside Milo's client, server, and stack architecture

The documented architecture separates the implementation into a shared OPC UA stack and higher-level SDKs. The stack is responsible for the protocol-facing concerns named in the README: channels, serialization, data structures, and security. The client and server SDKs sit on top of that foundation. This separation is the key implementation choice for evaluating the project, because it gives application developers a structured API while leaving the protocol machinery in a distinct layer.

The repository contains separate Maven modules under `opc-ua-stack/` and `opc-ua-sdk/`, with a root `pom.xml` coordinating the build. Published client and server artifacts are available under the `org.eclipse.milo` group, including `milo-sdk-client` and `milo-sdk-server`. A separate `milo-sdk-client-gds` artifact is documented for version 1.2.0 and later. That artifact is not a general server component. The README identifies it as a GDS client used to register an application with a Global Discovery Server, request certificates through the Pull Model, and read GDS trust lists.

The README does not provide a complete class-by-class data-flow description, so the exact connection lifecycle and serialization call sequence are not documented. The repository layout nevertheless confirms a modular design rather than a single client-only library. Milo's current OPC UA target is also worth checking against the server or device ecosystem that the application must interoperate with.

## Building Milo with the pinned Java toolchain

Milo pins its Java and Maven toolchain with `mise`. The README says to install that toolchain from the project root. If `mise` does not trust the configuration, review `.mise.toml` and trust it explicitly. The build then runs through `mise exec --`, which keeps the build on the pinned Java 17 and Maven versions.

The first documented build command is shown below. It is intended to be run from the project root after installing the pinned toolchain. A successful invocation reaches Maven's `clean install` lifecycle, but the README does not document the resulting console output or a test summary.

```shell
mise install
```

This installs the versions declared through the repository's `mise` configuration. If the tool reports that the config is not trusted, inspect `.mise.toml` before running the trust command below.

```shell
mise trust .mise.toml
```

Then build Milo with:

```shell
mise exec -- mvn clean install
```

The README recommends JDK 17 for compatibility, while stating that the library is runtime compatible with Java 17 and later, including JDK 21 and JDK 24. The repository includes a Maven project and a separate `milo-bom/` entry. The README does not document a binary installer, so a source checkout plus the documented Maven route is the appropriate first setup.

## Adding Milo's client or server SDK to a Maven project

For an existing Maven application, the README documents direct SDK dependencies. The versions shown in the dependency examples are `1.1.6`. Those examples describe the artifacts to use, but the README does not show a complete application class or a configuration file that performs an OPC UA request. For a first real use, follow the linked Wiki client or server tutorial after adding the appropriate dependency.

A Java application that needs the client SDK can declare this dependency. The group, artifact, and version are copied from the README.

```xml
<dependency>
    <groupId>org.eclipse.milo</groupId>
    <artifactId>milo-sdk-client</artifactId>
    <version>1.1.6</version>
</dependency>
```

A server application uses the server artifact instead:

```xml
<dependency>
    <groupId>org.eclipse.milo</groupId>
    <artifactId>milo-sdk-server</artifactId>
    <version>1.1.6</version>
</dependency>
```

The README links to First Server and First Client as the intended tutorials. It also points to the `milo-examples/` entry for runnable programs. It does not state that adding the dependency alone opens a connection, creates a server endpoint, or selects a transport security policy. Those details belong to the Wiki tutorial or example code.

## Milo's GDS client and version-specific capabilities

Version 1.2.0 introduces a distinct GDS client artifact in the README. The stated capability is narrower than ordinary OPC UA client access: it registers an application with a Global Discovery Server, requests certificates through the Pull Model, and reads GDS trust lists. The README labels this feature as available in `1.2.0 and later`.

The documented dependency uses a snapshot version:

```xml
<dependency>
    <groupId>org.eclipse.milo</groupId>
    <artifactId>milo-sdk-client-gds</artifactId>
    <version>1.2.0-SNAPSHOT</version>
</dependency>
```

A snapshot reference requires the Sonatype snapshot repository in the Maven `pom` file:

```xml
<repository>
    <id>sonatype-snapshots</id>
    <url>https://central.sonatype.com/repository/maven-snapshots/</url>
    <releases><enabled>false</enabled></releases>
    <snapshots><enabled>true</enabled></snapshots>
</repository>
```

This is a concrete upgrade constraint. The README says releases are published to Maven Central and snapshots to Sonatype. A production project should therefore distinguish a release dependency from a `SNAPSHOT` dependency rather than treating both as equivalent availability channels. The repository's recent release list includes `v1.2.0-RC1` and `v1.1.8`, while the dependency examples in the README still show `1.1.6`. Confirm the intended artifact version against the project release selected for adoption.

The README also points server guides to sampling and access-control material for roles and permissions, with that material marked for 1.2.0 and later. Those are documented feature areas, but the README does not define their configuration format or runtime behavior.

## Interoperability, maintenance, and adoption boundaries

Milo's current target is OPC UA 1.05, and the library is runtime compatible with Java 17 and later. These facts make version alignment the first technical check for an adoption decision. A Java 8 application would not fit the documented runtime range. An application that requires a different OPC UA specification version would also need verification because the README only states what Milo currently targets.

The repository is not archived, and its last push was on 2026-10-13. Recent release entries include `v1.2.0-RC1` dated 2026-10-12, `v1.1.8` dated 2026-10-06, and `v1.1.7` dated 2026-09-09. This supports recent project activity, but it does not by itself establish compatibility for a particular upgrade. The presence of both a 1.2 release candidate and 1.1 patch releases suggests that consumers may need to choose between a feature line and a maintenance line rather than blindly selecting the newest tag.

Milo is not the right choice if the required runtime is outside Java 17 and later, or if the target environment requires an OPC UA version other than 1.05 unless the project documentation confirms support. It is also a poor fit when the team needs a documented production installer or a README-level rollback procedure, because neither is described. The documented alternative source for operational guidance is the Wiki, not an inferred deployment process.

Compared with a general-purpose Maven library, Milo takes a protocol-specific route: it exposes OPC UA stack components and dedicated client, server, and GDS SDKs. Compared with a closed industrial connectivity component, it gives Java teams source access under EPL-2.0, but it also leaves device interoperability, endpoint configuration, certificate handling, and production deployment decisions to application-level documentation and testing.

## Conclusion

Java teams building OPC UA clients or servers should adopt Milo after checking its client, server, or GDS fit for their required version. Projects needing an established non-Java stack or a documented rollback process should verify those points first. The first practical check is the applicable Wiki tutorial and the pinned build command, `mise exec -- mvn clean install`.

## FAQ

### Which OPC UA version does Eclipse Milo target?

The README states that Milo currently targets OPC UA 1.05.

### How do I build Eclipse Milo from the repository?

Install the pinned toolchain with `mise install`, then run `mise exec -- mvn clean install` from the project root. If needed, review `.mise.toml` and run `mise trust .mise.toml`.

### Which Java versions are supported by Eclipse Milo?

The README recommends JDK 17 for building and says the library is runtime compatible with Java 17 and later, including JDK 21 and JDK 24.

### What does the Milo GDS client artifact do?

The `milo-sdk-client-gds` artifact, documented for 1.2.0 and later, registers an application with a Global Discovery Server, requests certificates through the Pull Model, and reads GDS trust lists.

## Sources

- [eclipse-milo/milo on GitHub](https://github.com/eclipse-milo/milo)
- [License: EPL-2.0](https://github.com/eclipse-milo/milo/blob/main/LICENSE)
- [Project website](http://www.eclipse.org/milo)
- [README](https://github.com/eclipse-milo/milo/blob/main/README.md)
- [Releases](https://github.com/eclipse-milo/milo/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eclipse-milo-milo
