Examples

Applies to Milo 1.2.0-SNAPSHOT. Source baseline 7faaf4f05, 2026-10-04.

This page indexes the runnable examples in the Milo source repository. Use Your first server and Your first client for the smallest complete programs. The source examples below demonstrate larger workflows and share an example server with a richer address space.

Tutorial programs and Wiki samples

The Wiki examples module contains the two tutorial programs and the compiled sources of the other Wiki code samples.

Run the examples

Use JDK 17 and import the pinned source checkout as a Maven project. Resolve its dependencies, then run the chosen class's main method from the client-examples module in an IDE. The source instructions describe the entry points, and Contributing links to the build prerequisites.

Most entries use ClientExampleRunner. It starts ExampleServer at opc.tcp://localhost:12686/milo and establishes mutual certificate trust between server and client. It then runs the client, disconnects, shuts down the server, and releases shared resources. Because the runner terminates the JVM, use it as a standalone process, not inside an application that hosts other Milo components.

ExampleServer binds every network interface on port 12686. It includes an unsecured anonymous endpoint and fixed demonstration credentials, so run examples only on a trusted host or network, or behind a firewall. Run one example at a time, and stop the tutorial FirstServer first, so ports do not conflict. Example trust is only a local demonstration, and your application must provision and validate trust itself.

The runner stores example keys and trust material under the JVM temporary directory, in client/security and server/security. Trust added by the runner persists there across runs. For an isolated run, set the JVM option -Djava.io.tmpdir=<dir> to a dedicated directory, and remove that directory only after the process has stopped. Keep production identities elsewhere.

The expected results below assume you launch each class from the command line with a resolved classpath and an isolated temporary directory. Compare the output with those results, and check the log for service or operation failures. At this baseline the runner can exit with status zero after logging an error, so exit status alone does not show success. For a port conflict, stop the other example. For an external server, check its advertised address, policy, identity, and trust instead of accepting any certificate.

Client learning path

Start with the first seven examples in order. Reverse Connect, GDS, and Alias Names are optional extensions. Each guide explains results, errors, and ownership in more detail.

Task	Runnable example	Guide
Connect and read	ReadExample	Reading
Browse	BrowseExample	Browsing
Write	WriteExample	Writing
Subscribe to values	SubscriptionDataExample	Subscriptions
Call a method	MethodExample	Methods
Receive events	SubscriptionEventExample	Subscriptions
Read and write custom types	ReadWriteCustomDataTypeNodeExample	Data types
Reverse Connect	ReverseConnectExample	Reverse Connect
GDS Pull	GdsPullExample	GDS client
Find aliases	AliasNamesExample	Alias Names

The first seven entries use the local example server and produce these results.

• ReadExample prints the start time, running state, and current time.
• BrowseExample lists the server's address space.
• WriteExample reports ten successful Int32 writes.
• SubscriptionDataExample receives current-time notifications.
• MethodExample prints sqrt(16)=4.0.
• SubscriptionEventExample receives event fields.
• ReadWriteCustomDataTypeNodeExample decodes a structure before and after a write.

Compare these results with the operation status checks in the topic guides. Several examples hard-code namespace index 2 for ExampleServer, but your application must resolve its server's namespace URI instead, as Your first client does.

ReverseConnectExample owns a local server and listener. It prints a connected endpoint, state, and current time. AliasNamesExample resolves Demo.%, reads a resolved target, and reports category information from the optional verbose Method. GdsPullExample requires the external setup below.

Server learning path

ExampleServer starts the server and its namespaces. Read the following components in order to see how application behavior fits together.

1. ExampleNamespace: Variables, references, types, and filters.
2. DeviceNamespace and DeviceSamplingGroup: device data and sampling.
3. SqrtMethod: a Method handler.
4. GenerateEventMethod: generating an event, in an older style whose flaws Events lists.
5. AlarmConditionsNamespace: Condition behavior.

These are components of the example server, not separate standalone programs. The Server SDK hub gives the guide's reading order.

External-server examples

• Prosys history read
• Legacy dictionary discovery

These source references assume a particular external address space, so adapt them to your server instead of treating them as portable launch configurations.

Reference	Required setup and expected result
Prosys history read	A history-enabled ns=3;s=Counter at opc.tcp://localhost:53530/OPCUA/SimulationServer, with trust provisioned between client and server. The example prints historical DataValues or an operation error. It reads one response and ignores any continuation point. Disconnecting releases the Session's resources. See Historical access for continuation-point handling.
Legacy dictionary discovery	A server exposing a legacy DataTypeDictionary and ns=3;s=Demo.WorkOrder.WorkOrderVariable. The hard-coded address opc.tcp://10.211.55.3:48010 comes from the author's environment, so change it. The example selects SecurityPolicy.None and prints the decoded structure. See Data types for the extra dictionary module and the current DataTypeDefinition approach.
GDS Pull	A configured GDS with certificate management, mutual trust, and an account authorized to register and sign. Set gds.endpoint, gds.username, and gds.password in the JVM launch settings. The defaults target opc.tcp://localhost:58810/GlobalDiscoveryServer and use demonstration credentials. The example finds or registers an application and requests a certificate for a throwaway key pair. It polls up to 30 times at two-second intervals (roughly 60 seconds) and prints the issued certificate. It does not install that identity but does replace selected local trust lists under java.io.tmpdir/client/security/gds/pki. Approve the GDS certificate in that directory, not the client/security/pki path the generic runner logs. Application records and signing requests remain in the GDS. After the run, clean them up there and clean up the local trust directory. See GDS client for workflow ownership.

Before you rely on one of these examples, verify the named server version, model, returned statuses, paging, certificate approval, and cleanup in your deployment. The repository README has the public demo server details.