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!)
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 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 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.
To explain what this update addresses, let's first take a look at the differences in behavior that were observed.
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.
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.
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:
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.
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!