RINEARN
HOMEINFOSOFTTECHAICONTACT
RINEARN > English Top > News > 2025
[ Prev | Index | Next ]
2025/04/22
Japanese English

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.

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
  • Major Updates Can Occasionally Cause Behavioral Changes
  • This Release Provides Compatibility Fixes for a Subtle Behavioral Shift
  • Behavioral Differences That Occurred
  • Background: About Network Drives
  • The Problem: Retrieving File Paths on Network Drives
  • Version 3.4.50: Implemented a Workaround to Prevent Expansion into UNC Format -- But Full Compatibility Isn't Guaranteed
  • Final Notes
  • If You Run Existing VCSSL Scripts on Java 24, Please Use VCSSL Version 3.4.50 or Later

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:

  • 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:

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!


Japanese English
[ Prev | Index | Next ]
RINEARN > English Top > News > 2025

Released: Latest Version of VCSSL with Fixes for Behavioral Changes on Java 24
2025-04-22 - VCSSL 3.4.50 released with a fix for a subtle behavioral change in absolute path resolution on network drives, introduced in Java 24. Details inside.

Index of this category
RINEARN > English Top > News > 2025
[ Prev | Index | Next ]
  • Released: Latest Version of VCSSL with Fixes for Behavioral Changes on Java 24
News

Released: Latest Version of VCSSL with Fixes for Behavioral Changes on Java 24
2025-04-22 - VCSSL 3.4.50 released with a fix for a subtle behavioral change in absolute path resolution on network drives, introduced in Java 24. Details inside.

Released the Latest Versions of RINEARN Graph and VCSSL - Now Supporting Customizable Tick Positions and Labels!
2024-11-24 - Starting with this update, a new "MANUAL" tick mode is now supported, allowing users to freely specify the positions and labels of ticks on the graph. We'll explain the details and how to use it.

Released Exevalator 2.2: Now Compatible with TypeScript and Usable in Web Browsers
2024-10-22 - The open-source expression evaluation library, Exevalator, has been updated to version 2.2. It now supports TypeScript and can be used for evaluating expressions directly in web browsers. Explains the details.

Behind the Scenes of Creating an Assistant AI (Part 1: Fundamental Knowledge)
2024-10-07 - The first part of a series on how to create an Assistant AI. In this article, we introduce the essential knowledge you need to grasp before building an Assistant AI. What exactly is an LLM-based AI? What is RAG? And more.

Launching an Assistant AI to Support Software Usage!
2024-09-20 - We've launched an Assistant AI that answers questions about how to use RINEARN software and helps with certain tasks. Anyone with a ChatGPT account can use it for free. We'll explain how to use it.

Software Updates: Command Expansion in RINEARN Graph, and English Support in VCSSL
2024-02-05 - We updated our apps. This updates include "Enhancing the Command-Line Features of RINEARN Graph" and "Adding English Support to VCSSL." Dives into each of them!

Inside the Repetitive Execution Speedup Impremented in Vnano Ver.1.1
2024-01-17 - Delves into the update in Vnano 1.1 from a developer's viewpoint, providing detailed insights into the specific improvements made to the internal structure of the script engine.

Scripting Engine Vnano Ver.1.1 Released: Dramatic Speed Improvement for Repetitive Executions of the Same Content
2023-12-22 - Released the Vnano script engine Ver.1.1. In this version, we've made significant enhancements in processing speed by reducing the overhead of handling requests. Explains the details.

» View More Articles
See Our News
on Twitter !
RINEARN Official Website | Top Page | Privacy Policy |
This website uses cookies for serving ads and analyzing traffic data. By continuing to use this website, you agree to our privacy policy.
This website is managed by RINEARN. All rights to the contents of this website are owned by RINEARN and its owner.
Copyright(C) RINEARN 2009 - 2025 All rights reserved.