question about Files.move for version 1.2.4

[hubfruser]

Hello, I have a question about moving or renaming file using this library. Appreciate any feedback.

background:
aws-java-nio-spi-for-s3 1.2.4
Not able to use 2.0.0 because I have to stick with JRE 8 and am not able to use higher version (JRE 11, etc). Version 2.0.0 seems not compatible with JRE 8 because I saw some errors.

Below was the code I used:

  String S3_BUCKET = "s3://mybucket";
  URI s3uri = URI.create(S3_BUCKET);
  String fileName = "testfile";

  try (FileSystem fileSystem = FileSystems.newFileSystem(s3uri, Collections.EMPTY_MAP)) {//for 1.2.4, it seems I may have to create a Filesystem instead of default one which access windows traditional file system on my machine.
      Path filePathTmp = fileSystem.getPath(fileName + ".tmp");  
      Path filePath = fileSystem.getPath(fileName); 
      String content = "hello s3";

      Files.write(filePathTmp, content.getBytes(StandardCharsets.UTF_8));

      Files.move(filePathTmp, filePath, StandardCopyOption.REPLACE_EXISTING);
  } 

I expected "testfile.tmp" get created first, then renamed(moved) to "testfile".
But what actually happened was that "testfile.tmp" was created first with content of "hello s3", then it was moved into a folder named "testfile". No file "testfile" exists except this folder.

I tried to use Files.copy then File.delete to replace Files.move, the result was the same (Files.move actually was implemented as Files.copy + Files.delete).

I wonder if I did anything wrong above or if there was anyone else had experienced this. Thanks for your time.

[markjschreiber]

I think your approach looks ok so there may be a bug. I know that when moving to V2 we made several changes to make the package interact more "normally" with the Files class. It would be worth trying the example with V2 to see if it works as expected there as it might be possible to back-port some changes to v 1.2.4

Although you may not have much choice in this I would strongly recommend moving to a newer LTS version of Java as JRE 8 is (depending on the build) EOL.

[hubfruser]

Thank you, Mark, for your reply. Is it convenient to fix in V1 , or somehow make V2 compatible with JRE 8?

Latest release (2.0.0.rc1/rc2 ) seems not compatible with java 8. It seems compiled with java 11.

I got runtime error below when I ran a test using the 2.0.0.rc1 or rc2:

java: cannot access software.amazon.nio.spi.s3.S3FileSystemProvider

C:\test\src\main\java\s3nioTest.java:3:34
bad class file: /C:/......./jbr/build-env/paygovRepository/software/amazon/nio/s3/aws-java-nio-spi-for-s3/2.0.0-rc1/aws-java-nio-spi-for-s3-2.0.0-rc1.jar!/software/amazon/nio/spi/s3/S3FileSystemProvider.class
class file has wrong version 55.0, should be 52.0
Please remove or make sure it appears in the correct subdirectory of the classpath.

the line 3 in my test was an import line:

import software.amazon.nio.spi.s3.S3FileSystemProvider;

Using version 1.2.4, there was no above error except the issue of my first post.

I understand the latest version (V2) has fixed and improved over V1. It's just my situation which make me to stay with JRE 8 for a while. The decision to upgrade JRE is beyond my control. Upgrading JRE major versions may require code changes which my people are not ready yet (there may be other libraries compatible or test verification concerns, etc and may need to be upgraded together with JRE upgrades).

I think there are other people in the same situation. There are people who have trust in this library because it resides in awslabs. If there is not other choice, it seems I may have to wait until my JRE could be upgraded in future, then use this library. Thank you for your effort to make it available.

[markjschreiber]

V 2.0.0 does require Java 11 or above and has some dependencies that require Java 11 or above so it wouldn't be possible to revert it to use JDK 8.

Although I don't wish to maintain two versions of the library it might be possible to patch v 1.2.4 to remove this error. Can you file an issue in the "issues" section of the repository? If you could provide any context as to where you think the issue might originate that would help speed up a fix.

That aside I would also recommend that you advocate for your organization to update their Java version to a higher LTS version such as 17 or 21. Although we build for Java 11 there are significant performance benefits to these later versions. In addition, depending on the vendor of you Java 8 build you may not be receiving security updates (or you might be paying for them).

[hubfruser]

Thank you, Mark for the option of possible patch. I will create an issue. Will do about your recommendation of the java upgrade.