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:

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.

A note regarding this issue:

The behavioral change that caused this issue has been reported to the Java Bug Database and accepted as issue JDK-8355342: File.getCanonicalPath on Java 24 resolves paths on network drives to UNC format. Although the fix schedule has not been determined yet, it may be addressed in a future release.

I'd like to take this opportunity to thank the OpenJDK community members for looking into this, and also extend my appreciation to ChatGPT (GPT-4o) for its tremendous help in preparing and submitting the issue report. (I'm hoping to write a more detailed article about this experience sometime soon!)

- Table of Contents -

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.

For example, a notable case in recent years was the change of the default character encoding to UTF-8. This led to potential issues like text garbling in legacy processing, which required widespread countermeasures.

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:

\\192.168.1.3\share\

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:

\\192.168.1.3\share\a.txt

can be accessed via:

Z:\a.txt

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:

import File;

// Retrieve the absolute path of a file on a network drive
// (Passing an absolute path directly here for clarity)
string absolutePath = getFilePath("Z:\a.txt");

// Print the result
println("Retrieved absolute path: " + absolutePath);

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

(Java 23 and earlier)
Retrieved absolute path: Z:\a.txt

(Java 24)
Retrieved absolute path: \\192.168.1.3\share\a.txt

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.

Just to clarify for Java's sake -- UNC-style paths are still technically valid. Also, whether a network drive gets resolved like this is not strictly defined in the Java API used here, so this behavior is implementation-dependent. Therefore, it can't be considered a bug-though it's unclear whether this change was intentional on the Java side.

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:

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:

Retrieved absolute path: Z:\a.txt

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.

As a side note, it's possible that this change in behavior on Java's side was not intentional -- if so, it may be reverted in Java 24.0.2 or 25. On the other hand, since the relevant feature is implementation-dependent, similar subtle behavior shifts could still occur in the future.

Unfortunately, there's no perfect way to prevent that, and we're very sorry about it. If your scripts depend critically on specific path formats, we recommend keeping a copy of the Java Runtime Environment (JRE) that was used when the script was originally written-just in case.

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