Description of problem: I see Java places some configuration files in .java. In my system, I have .java/fonts/1.8.0_25/fcinfo-1-mether-RedHat-21-en.properties Please fix Java to follow xdg base dir spec. IcedTea has already adopted it (based on my earlier bug report) References: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html A non spec rationale http://ploum.net/207-modify-your-application-to-use-xdg-folders/ The relevant API's (glib specific but equivalents are available in other places as well) https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-user-cache-dir https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-user-config-dir https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-user-data-dir
No meeter how I sympathize eith xdg, this is nearly impossible to fix. Openjdk is supposed to run on windows. I can not simply forward any patch which will move windows to free desktop specification. Also I feel quite uneasy to add any spec-only patch for this. Icedtea is linux-only, so it can do such a things without problems.
The glib API I references already handles Windows vs Linux by placing files in the appropriate location. The configuration paths are already different between these platforms anyway
I'm not aware of any change for this in IcedTea either, and it's certainly not "linux-only". We've had people build it on both *BSD and Windows in the past.
IcedTea did change based on my earlier bug report. C.f. https://bugzilla.redhat.com/show_bug.cgi?id=947647 Also, I don't see why the xdg spec wouldn't apply to any Linux, BSD etc. Windows already has a very different path and the glib API handles those differences just fine.
That's IcedTea-Web, not IcedTea. The Windows argument is spurious in the case of these .fcinfo files that I wasn't aware of until this bug report. These are fontconfig configuration files and are created in POSIX-specific code. The directories are also specific to each update of OpenJDK, so moving it doesn't really need to be backwards-compatible either. So I think it's possible to clean this up. However, it should be noted that '.java' is used elsewhere as the default for the user preference root. This can be overridden manually by setting java.util.prefs.userRoot but the default should really be fixed there too. The solution is probably to obtain a user preference directory from native code, and fall back on the old version if this is unavailable. There is precedent for using GLib already in the POSIX code.
I still see this with the latest version of OpenJDK Users could override it: export _JAVA_OPTIONS=-Djava.util.prefs.userRoot="$XDG_CONFIG_HOME"/java but I am hoping we can update the default handling
(In reply to Rahul Sundaram from comment #6) > I still see this with the latest version of OpenJDK > > Users could override it: export > _JAVA_OPTIONS=-Djava.util.prefs.userRoot="$XDG_CONFIG_HOME"/java but I am > hoping we can update the default handling This doesnt work for me. The ".userPrefs" is created in "$XDG_CONFIG_HOME"/java, but java still creates $HOME/.java/fonts