Resolving FactoryPMI Designer Startup Error in Java 6

The java.lang.ArrayIndexOutOfBoundsException: No such child: 2 message at FactoryPMI Designer startup is a user-interface compatibility defect, not a project or communications failure. It occurs when the docking framework used by FactoryPMI v3 interacts with later Java 6 releases; the reported installation used FactoryPMI v3.3.2 build 2754 and Java 1.6.0_14. If the Designer continues to operate, record the exception as harmless and plan migration to FactoryPMI v4, the stated correction target.

Symptom Classification

Classify the failure from the exception type and the first product-specific frames in the stack trace. The term stack trace here means the ordered list of methods active when Java raised the exception.

Do not combine these signatures merely because both appear during launch. An interface event exception and a resource-download failure occur in different layers and require different tests.

Docking-Framework Mechanism

FactoryPMI v3 uses a docking framework that manages split panes, docked windows, and component visibility. Java delivers visibility changes through the Abstract Window Toolkit event queue. In the reported trace, componentHidden calls setDividersVisible, which then asks the container for child index 2. The container has no child at that index, so Java raises the bounds exception.

The failure therefore occurs during interface layout handling on the Java event-dispatch thread. It does not identify a failed PLC connection, corrupt project resource, unavailable gateway, or download problem. Those conditions require their own diagnostic evidence.

A caught interface exception can leave the application usable because the rejected operation concerns docking presentation rather than the Designer's core editing transaction. The decisive observation is functional: verify that the application opens, panels respond, and project operations remain available after the message.

Affected-Version Boundary

The known interaction involves the docking framework in FactoryPMI version 3 combined with later Java 6 releases. Java 6 update 12 and later were identified as the suspect range, and the supplied installation reports Java 1.6.0_14. The FactoryPMI installation is v3.3.2, build 2754.

Read the runtime version from the launch diagnostics or exception report rather than relying on the Java version believed to be installed. A workstation can contain multiple runtimes, while the launcher selects one runtime for the actual process.

Corrective Procedure

1. Capture the exact signature. Record the FactoryPMI version, build, Java runtime, exception text, and the first FactoryPMI or docking-framework methods. Match the interface defect only when the trace includes No such child: 2 and the JideSplitPane visibility calls.
2. Test operation after dismissal. Close or acknowledge the error display, then exercise the Designer functions needed for the work session. If the Designer remains responsive, classify the event as a non-fatal interface defect.
3. Separate concurrent launch faults. If the trace instead contains FailedDownloadException or Connection reset, test access to the configured Designer resource and inspect the FactoryPMI logs, normally under C:\Program Files\Inductive Automation\FactoryPMI\logs. Do not use the docking-framework diagnosis for that condition.
4. Select the correction path. Test migration from FactoryPMI v3 to FactoryPMI v4 because v4 is the stated target for correcting this docking-framework interaction. Follow the applicable product upgrade procedure and validate the project in a controlled environment before changing an operating workstation.
5. Manage a deferred upgrade. When the installation must remain on v3, document the recognized signature and its non-fatal acceptance criteria. Do not tell operators to ignore every Java exception; acceptance applies only when the signature matches and the functional checks pass.

Replacing networking components, modifying PLC addresses, or rebuilding project communications cannot correct a bounds exception generated by a split-pane visibility event. Likewise, changing Java solely to suppress the message introduces a runtime change that requires a complete application compatibility test.

Verification Criteria

1. Check 1: exception identity. Expect the non-fatal case to show java.lang.ArrayIndexOutOfBoundsException: No such child: 2 with JideSplitPane.setDividersVisible and JideSplitPane.componentHidden.
2. Check 2: launch completion. Expect the Designer window to finish opening rather than terminate at the exception.
3. Check 3: interface response. Expect docked panes and the required editing views to open, close, and respond to input after the message.
4. Check 4: fault separation. Expect no FailedDownloadException or SocketException: Connection reset in the trace being classified as the docking defect.
5. Check 5: corrected-version test. After migration testing, expect FactoryPMI v4 to launch on the selected runtime without the No such child: 2 stack trace and with the required Designer functions available.

Recurring Diagnostic Pitfalls

The most common wrong practice is grouping all startup messages under one root cause. A Java collection or container exception describes invalid software state inside the process; a socket reset describes a broken transport transaction. Similar timing does not make them related.

Another mistake is treating “harmless” as meaning “unclassified.” Preserve the complete trace and verify the application after every occurrence. A different exception, a changed top frame, or loss of Designer function starts a new diagnosis.

Avoid declaring the issue fixed merely because the dialog disappeared. The correction criterion is both absence of the known exception and successful operation of the Designer views used by the project. Also avoid representing Java 6 update 12 as an exact universal cutoff: use it to identify the compatibility range to test, while the active runtime string and repeatable behavior decide the workstation result.

FAQ