yavijava
Sign In Get Started

vSphere 9 support is in

· releases, vsphere-9

vSphere 9.0 shipped earlier this year and yavijava 9.0.0 is now caught up. This is a quick note on what was involved and how to bring it into your project.

What was involved

yavijava is generated code, not hand-written. The vSphere API surface ships as a WSDL plus a tree of XSD schema files; we read those and emit roughly 4,000 Java classes covering every DTO, every enum, and the SOAP stub.

For 9.0 the work broke down into five steps:

  1. Refresh the source-of-truth WSDL. Pull vim.wsdl and its XSD includes from a vSphere 9.0 ESXi host. Diff against the 8.0 set. This is where surprises hide — VMware adds, deprecates, and occasionally renames types between major versions, and silently dropping a type out from under callers is the failure mode you want to catch before you ship.

  2. Re-run the generator. The generator walks the WSDL and emits the DTO classes, enums, and VimStub.java. New 9.0 types (refreshed storage policies, content libraries, vTPM, the new vCLS bits) come along for the ride.

  3. Regenerate managed objects from the pyVmomi schema. Managed-object classes don’t live in the WSDL directly — they’re metadata baked into VMware’s pyVmomi library. We mirror that schema as a JSON snapshot and emit our MO classes from it. For 9.0 this is esx/pyvmomi-schema-9.0.0.json in the generator repo.

  4. Reapply hand-fixes to VimStub.java. A handful of generator edge cases need manual touch-ups every release. They’re documented in REGEN-NOTES.md so they’re not lost between releases.

  5. Test against vcsim. govmomi’s vSphere API simulator is the loop for verifying request/response wiring without standing up a real vCenter. Integration tests point at vcsim by default for CI; a live vCenter is only needed for the SSO bearer-token integration.

The whole regen-to-release cycle is a long afternoon once the WSDL is in hand.

What this means for your project

yavijava 9.0.0 is a drop-in replacement for VIJAVA and prior yavijava versions. The public API surface — ServiceInstance, Folder, VirtualMachine, the full managed-object hierarchy — is preserved. Code written against yavijava 8.x compiles unchanged. vSphere 9 servers expose new types and methods that older builds simply didn’t know about; on 9.0.0 those are now reachable.

Using it

Maven:

<dependency>
    <groupId>com.toastcoders</groupId>
    <artifactId>yavijava</artifactId>
    <version>9.0.0</version>
</dependency>

Gradle:

implementation "com.toastcoders:yavijava:9.0.0"

A minimal connection:

import com.vmware.vim25.mo.ServiceInstance;
import java.net.URL;

ServiceInstance si = new ServiceInstance(
    new URL("https://vc.example.com/sdk"),
    "administrator@vsphere.local",
    "password",
    true);     // ignore self-signed certs in dev
System.out.println(si.getAboutInfo().getFullName());
si.getServerConnection().logout();

If you’re coming from VIJAVA, the only change is your groupId:artifactId coordinate — net.java.dev.vijava:vijava becomes com.toastcoders:yavijava. Nothing in your code needs to move.

For first-time users, the Getting Started guide walks through the rest.

Coming next

The commercial library yavijava-sso tracks yavijava versions. The current SSO build is compatible with yavijava 9.0+ and adds bearer-token authentication against vCenter’s built-in STS — no wsimport, no CXF, no external IdP needed. If you’ve been hand-rolling WS-Trust against vCenter, it’s worth a look.

← Back to all posts