Java SE 6 and Java SE 8 JRE behave differently in Windows 7 (file permissions)

Question

I have a Java command line application that reads and writes files on a Windows 7 x64 platform. Currently, the application works with the supplied IBM Java SE 6. The structure is as follows:

APP_ROOT some_folder jre bin lib myjarfile.jar appl_start.bat 

Now I replaced the jre folder with the unpacked JRE 8 package. And the application started complaining that it could not “access” (in fact, this is a write operation) in some_folder. If I manually create new some_folder_1 under APP_ROOT and reconfigure the application to use it, the application works fine. If I delete the recently created some_folder_1 and rename some_folder to some_folder_1, an application complaining that it cannot access it (even in read mode).

If I replaced the jre folder with JRE 6 files, the application will start working normally.

I tried to compare effective permissions through properties - everything looks the same, nothing suspicious. UAC is turned on, I work and do a folder replacement under the normal user.

UPDATE . After I disabled UAC in Windows 7 and rebooted, the application started working with JRE 8. But I need to get it to work with enabled UAC. When you restart UAC to power on and reboot, the application with JRE 8 again failed. I also noticed that JRE 8 does not create the appropriate files in "C: \ Users \ username \ AppData \ Local \ VirtualStore \ Program Files (x86) \", where it is usually created when a program tries to write inside Program Files.

UPDATE 2 . There were more problems finding and troubleshooting:

• An application with JRE 8 crashes only when writing to "C: \ Program Files \ APP_ROOT \ some_folder"
• According to the design of Windows 7, in this case the file should be created in C: \ User .. \ VirtualStore, but JRE 8 cannot do this ( which is incorrect and the root of the problem ).
• JRE 6 can create files in VirtualStore.
• VirtualStore content was cleared before restarting with JRE 8
• A successful launch with a combination of "some_folder_1" and JRE 8 was that JRE 8 actually wrote inside C: \ Program Files / APP_ROOT / some_folder_1, which is a violation of IMHO. Thus, this is another problem: why did the JRE 8 not redirect the write to the file system in VirtualStore and did not insert the C: \ Program Files subdirectory.
• If I define% localusrdir% in some directory C: \ temp, JRE 8 shows the same problem, so this is not only the specific problem of the VirtualStore folder, IMHO.

So, I conclude - for some reason, JRE 8 cannot redirect the output record to C: \ Program Files ... to C: \ Users ... \ VirtualStore

How can this be fixed, so JRE 8 will start writing to VirtualStore in order than JRE 6?

UPDATE 3 : unsuccessful version of JRE:

 C:\Program Files (x86)\APP\jre\bin>java.exe -version java version "1.8.0" Java(TM) SE Runtime Environment (build pwi3280-20150129_02) IBM J9 VM (build 2.8, JRE 1.8.0 Windows 7 x86-32 20150116_231420 (JIT enabled, AOT enabled) J9VM - R28_Java8_GA_20150116_2030_B231420 JIT - tr.r14.java_20150109_82886.02 GC - R28_Java8_GA_20150116_2030_B231420 J9CL - 20150116_231420) JCL - 20150123_01 based on Oracle jdk8u31-b12 

Answer 1

You do not have. JRE 8 probably tells Windows not to redirect, and I would have thought you couldn't change anything. (By the way, automatically redirecting to VirtualStore is a feature of Windows, not Java.)

VirtualStore is for old and wrong programs, not new ones. You must store your data where the user / application data should be , in which case it will be in AppData. If you have existing data (for example, an update from an old program), you must transfer data from this location to a new one that the user can write.

If you need to allow multiple users to write to the same files, you may have to change the permissions of the ACL / files so that these other users can write to the same files - this does not require administrator rights.

Alternatively, the user can take on the access rights / add write permissions to APP_ROOT, but this will require administrator rights.

Finally, if you really want to use VirtualStore, then you can probably find the JRE version (or try to read / write and catch the exception) and directly use the VirtualStore path, which you can most likely write to normally if necessary.