Java SE 6 and Java SE 8 JRE behave differently on Windows 7 (files permissions)

Question

I have a command line Java application which reads and writes files on Windows 7 x64 platform. Currently application runs with shipped IBM Java SE 6. Structure as follows:

APP_ROOT
    some_folder
    jre
        bin
        lib
    myjarfile.jar
    appl_start.bat 

Now, I replaced the jre folder with unzipped JRE 8 package. And the application started complaining that it can not "access" (actually it's write operation) files in some_folder. If I create manually new some_folder_1 under APP_ROOT and re-configure application to use it - application runs just fine. If I delete newly created some_folder_1 and rename some_folder to some_folder_1 - application complaining that it can't access it (even in read mode).

If I replace jre folder with JRE 6 files - application start working fine.

Tried comparing effective permissions via Properties - all looks the same, nothing suspicious. UAC is turned on, I'm working and doing folders replacement under regular user.

UPDATE: After I turned off UAC in Windows 7 and rebooted, application started working fine with JRE 8. But I need to make it working with UAC turned on. When reverted UAC to on and rebooted - application with JRE 8 failed again. Also, noticed that seems JRE 8 does not create properly files in "C:\Users\username\AppData\Local\VirtualStore\Program Files (x86)\", where it normally create when program attempts to write inside Program Files.

UPDATE 2: Did more troubleshooting, and narrowed problem:

1. Application with JRE 8 fails only when it writes to "C:\Program Files\APP_ROOT\some_folder"
2. By Windows 7 design in this case file expected to be created in C:\User..\VirtualStore, but JRE 8 can not do this (which is wrong and the root of the problem)
3. JRE 6 can create files fine in VirtualStore.
4. VirtualStore content was cleaned up before re-run with JRE 8
5. The succeeded run with "some_folder_1" and JRE 8 combination was because JRE 8 actually wrote inside C:\Program Files/APP_ROOT/some_folder_1 - which is violation IMHO. So, this is another problem - why JRE 8 did not redirect writing to filesystem in the VirtualStore, and modified instead C:\Program Files subfolder.
6. If I define %localusrdir% to some C:\temp directory, JRE 8 shows the same problem, so it's not only specific problem of VirtualStore folder, IMHO.

So, I make conclusion - for some reason JRE 8 can not redirect writing output to C:\Program Files... into C:\Users...\VirtualStore

How it can be fixed, so JRE 8 start writing in VirtualStore fine as JRE 6 does?

UPDATE 3: the failing JRE version:

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

Greaten

Answer 1

You don't. JRE 8 is probably telling Windows not to redirect and I'd imagine that's not something you can change. (By the way, automatically redirecting to VirtualStore is a Windows feature, not a Java one.)

VirtualStore is meant for old and misbehaving programs -- not for new ones. You should be storing your data where user/application data is meant to go, and in this case it would be in AppData. If you have existing data (e.g. this is an upgrade from an old program) then you should migrate the data from that location to a new one that the user can write to.

If you need multiple users to be able to write to the same files then you may have to modify the ACLs / file permissions so that those other users can write to the same files -- this shouldn't require admin rights.

Alternatively, the user could take ownership of / add write permissions to the APP_ROOT but that would require admin rights.

Finally, if you really want to still use VirtualStore, then you can probably detect the JRE version (or make an read/write attempt and catch the exception) and use the VirtualStore path directly, which is likely something you can write to normally if so desired.

Natal

Yes, exactly - the OPs can either fix his software or keep using Java 6. (I'd suggest removing the part about using the VirtualStore path directly, because what that path is might depend on which version of Windows is running, perhaps even on the language version.) – Centralize

Keilaron, while I appreciate your answer, two points: 1) This is a legacy application and nobody wants to rewrite it because of Java 8 started working differently than earlier JREs. 2) JRE 6 works fine, so telling it's OS level issue not fully accurate. – Greaten

@BaratSahdzijeu: is isn't an OS level issue, it's a bug in the application that the OS happened to work around via a compatibility fix. If you're not willing to fix the bug, you'll just have to stick to Java 6. (Well, I suppose IBM might be able to provide you a pre-Vista executable that implements the Java 8 runtime, or you might be able to build one yourself. But you really should fix the bug.) – Centralize

Note that Windows chooses whether to apply the compatibility fix based on information contained in the executable, in this case java.exe or equivalent. For example, whether the executable claims to support Windows Vista or not. That's why changing the runtime changes the behaviour, even though the compatibility fix is in Windows rather than being part of the runtime. – Centralize

Harry, how can I determine myself if pre-Vista features exist in .EXE or not? Is there any tool which inspects .EXE and says - this one supports VirtualStore, and this one - not? – Greaten

I'm not trying to be pedantic nor a jerk, here -- you're really in a bad situation. As for rewrite -- what? One of the options presented was to add a conditional -- it's not that much work. There are a few alternate options you can try, but I believe they both require admin rights: Set the JRE to be executed in compatibility mode, which may cause Windows to use VirtualStore regardless, or disable UAC and/or run as admin. – Natal