Released: Latest Version of VCSSL with Fixes for Behavioral Changes on Java 24

RINEARN has recently released version 3.4.50 of VCSSL. You can download the latest version from the following page:

• Download the Latest Version of VCSSL

This release does not include new features, but instead focuses on handling a subtle behavioral change introduced in the Java 24 environment compared to earlier versions.

Details are explained below.

Java 24 Released Last Month

About the Release of Java 24

The VCSSL interpreter is implemented in Java and runs on the Java runtime environment (Java Virtual Machine).

Although Java development stagnated for a while in the past, it has recently become more active, with major version updates occurring roughly every six months (spring and fall).

Last month, the latest major release of the Java language and runtime -- Java 24 -- was made available.

Major Updates Can Occasionally Cause Behavioral Changes

Major updates of the Java language and environment can, in some cases, alter the behavior of existing code. While the language design aims to avoid such breaking changes as much as possible, there are rare situations where the behavior of implementation-dependent features may change between versions.

As a result, software running on the Java runtime - including the VCSSL execution environment and other Java applications - can sometimes experience behavioral shifts as well.

This Release Provides Compatibility Fixes for a Subtle Behavioral Shift

This time, the situation is similar.

Details are explained later in this article, but in short, a subtle change occurred in how file paths are handled under certain conditions (in an implementation-dependent feature), differing between Java 23 and Java 24.

While the paths obtained in VCSSL running on Java 24 aren't exactly wrong, the format is slightly different under certain specific conditions. This may not be a problem in newly written VCSSL scripts.

However, for older scripts, a difference in path format may lead to unintended behavior, since the format no longer matches what was originally expected.

Although completely eliminating this kind of "slightly changing behavior depending on environment or version" is difficult, we want to minimize it as much as possible.

So, in this update, we've introduced a workaround in the VCSSL interpreter to restore behavior as close as possible to the pre-Java-24 environment for affected cases.

Behavioral Differences That Occurred

To explain what this update addresses, let's first take a look at the differences in behavior that were observed.

Background: About Network Drives

First, some context. On Windows, shared folders on other PCs across a network can be mapped as network drives, allowing them to be accessed just like local drives (such as the C: drive).

For example, let's say a PC on the local network at IP address 192.168.1.3 is sharing a folder. The UNC (Universal Naming Convention) path for that might be:

If this folder is mapped to network drive Z:, then Z: will appear as a drive on the local PC, and its contents will correspond to the shared folder. So, a file such as:

can be accessed via:

Even nested folder structures behave the same way.

The Problem: Retrieving File Paths on Network Drives

In VCSSL, you can use the getFilePath function from the File library to retrieve the absolute path of a file.

However, under Java 23 vs Java 24, the behavior of this function differed when used to retrieve the absolute path of a file located on a network drive.

For example, the following VCSSL script is affected:

When run in Java 23 and Java 24 environments, the results differ:

As shown, when running on Java 24, the VCSSL interpreter expands the Z: network drive part into its UNC path (\\192.168.1.3\share). In contrast, Java 23 and earlier simply preserved the network drive notation.

Side Effects

Depending on the behavior of your VCSSL scripts, this "conversion to UNC path" may cause unintended issues.

Specifically, it can affect cases where VCSSL scripts execute external processes (like .exe files or commands) and those involve network drives.

This is because, when working with Windows commands via Java, there are many cases where UNC paths cannot be used.

For example, in Windows Command Prompt, you can't set a UNC path as the current directory. Also, UNC paths often don't work as working directories for external processes launched via Java.

So if you're doing any of the following, your script might fail unexpectedly:

• Launching .exe files located on network drives as external processes from VCSSL scripts
• Running VCSSL scripts themselves from a network drive and setting that location as the working directory for a subprocess

Version 3.4.50: Implemented a Workaround to Prevent Expansion into UNC Format
-- But Full Compatibility Isn't Guaranteed

In version 3.4.50 of VCSSL, we modified the internal path resolution logic to bypass the behavior that expands paths into UNC format, as observed above.

As a result, in the earlier code example, running VCSSL on Java 24 now produces the same result as on Java 23 and earlier:

However, both the original and revised methods of obtaining absolute paths rely on Java API features whose behavior is implementation-dependent.

So, this update doesn't guarantee full behavioral equivalence in every edge case. It's even possible that some tricky input cases might behave differently due to this change.

That said, because the impact of the UNC conversion was significant, we prioritized restoring compatibility in that area.

Final Notes

If You Run Existing VCSSL Scripts on Java 24, Please Use VCSSL Version 3.4.50 or Later

That wraps up the explanation of the behavior addressed in this update.

We apologize for any confusion or inconvenience. If you plan to run previously written VCSSL scripts on a Java 24 environment, please make sure to use VCSSL version 3.4.50 or later.

If you encounter any remaining behavioral differences, feel free to send us your script (or a code snippet), and we'll investigate.

We'll continue to share updates about VCSSL in this news section, so stay tuned!