Invalid preferences format

[ArvidNy]

For some reason, I get the above error each time I try to open previous settings. After some investigation, this seem to be because of characters that are stored that the preference file does not support. This is an example of a preference:

<entry key="/&#29;��Lϙ ��`��L?�H}=&lt;�&#9;�H�}&#23;��#=" value="0"/>

Note how it says e.g.  instead of the character it is supposed to show. Removing those characters made the preference file open again. Changing this line to the line below resolves the issue for me.

return Base64.getEncoder().encodeToString(messageDigest.digest());

Has anyone else noticed this issue and would there be any other problems with changing the line to the above?

[martinfrancois]

That's very strange... the SHA-256 representation of a string shouldn't contain characters that strange.
Can you maybe try to isolate which key, i. e. which name a setting needs to have, to return the "Invalid preferences format" error? We've never seen it before, so we would be very interested in knowing that.
I guess it doesn't happen with the demo, right?

[ArvidNy]

I happens with any kind of string, including the demo strings. Not sure if this might be an OS-related issue? I'm using Manjaro Linux.

[martinfrancois]

Might be OS related, I will have a look if I can reproduce this issue with Manjaro.

[martinfrancois]

Hi @ArvidNy
I was now able to reproduce this issue in Manjaro.
I noticed that when saving the preferences, it would use this key (sha256 hash): Y<Z��Z����c���4���O'W٢���� +�K�
Instead of the correct encoding for this hash, which would be: 593c5a0b845a1d869db3631caefc34bcbc194f2757d9a2d001bd98002b1e4bad

Therefore, I implemented #55, in which I changed the encoding to be correct in all circumstances.
Can you please check if the issue still persists when you use #55? The first time, it should log a warn message, saying that the keys will be migrated. In subsequent launches, it shouldn't happen anymore.

[ArvidNy]

Just checked this out and it seems to work now. I didn't get any warning saying that the keys would be migrated, just the previous warning saying it had an invalid preferences format, but after that it worked as expected. However, since no settings have been successfully stored before, no settings had to be migrated anyways. I supposed that's only relevant/valid for user without these issues.

[martinfrancois]

Thanks @ArvidNy! So did I understand this correctly, in subsequent launches after the initial error, everything worked fine?

[ArvidNy]

That's correct, @martinfrancois.

[martinfrancois]

Thanks! In this case, I will merge the changes.

[Adyel]

This needs to be fixed for JDK8 too. Can you please update. @ArvidNy
Is there any other way I can fix it myself?

[ArvidNy]

@Adyel, this works for me with JDK8 now. If you still have issues, you should provide @martinfrancois and the other members of the project with more information about what you are experiencing and I'm sure they'll help you out when they get the chance. A way around it is to create your own store handler class where you could set it up to store the preferences any way you'd like, using this class as a foundation, and use that as the first variable before any other categories:

PreferencesFx.of(new CustomStorageHandler(parent),
    Category.of("Category Title",
            Group.of("Group Title",
                Setting.of("Setting Title", new Property())
            )
        )
    );

[seamlik]

@ArvidNy He means this should be fixed in the JDK 8 branch of PreferencesFX. Apparently the fix has not been merged for that branch. For now I am using version 2.1.0 and the bug remains.

[ArvidNy]

@seamlik, as far as I can tell the fix #55 is merged into the main branch, they just haven't created a new release yet. I also look forward to the next release but I suppose they've been busy and haven't been able to work on the project for a while.

[martinfrancois]

@seamlik yes, @ArvidNy is correct. It's fixed, but not released yet. We are working on getting out a release soon. Thanks for your patience!

[martinfrancois]

Hi @Adyel @ArvidNy @seamlik
The fix for this issue was included in release 8.3.0 (for Java 8) and 11.3.0 (for Java 11), which has just been released.