Error under new version

I'm surprised you get even that far with JDK 13 as i don't even see that class as being present. In your case it looks like it's being loaded so must be there somehow (perhaps you're not using 13 as you think) but missing the method you're using

i don't even see that class as being present

Which class do you mean, CEHJ please?

----------
The same error arrives courtesy of Java 12.0.2 as well.

java.util.prefs.WindowsPreferences

Select allOpen in new window

So the Java 8 classloader behaves differently or has different params to those of later versions viz 12 and 13 ?

There's some difference yes. Please include this as your first line of main while testing so we can be sure what's happening

System.out.printf("Java version is %s%n", System.getProperty("java.version"));

Select allOpen in new window

Thank you.

Right, well I have placed that line of code into main() at the top.  Presently it reports 12.0.2, which is in line with expectations and settings.

Three versions are on the machine presently that can be implemented : 13.0.2, 12.0.2, and 1.8.0_66.

(When pointing the enviro to a different release, I query the current state with the command-line "java -version" first to be sure. (Tedious of course due to reboot req)).

(Tedious of course due to reboot req)

Well if you're set up correctly, i'm not sure that should be necessary., with %JAVA_HOME%\bin as part of PATH.

You can of course try

<full path to java>\java.exe ...

Select allOpen in new window

too

OK well it seems that the machine needs rebooting each time even when %jAVA_HOME%\bin is in the PATH. But anyway, I'll suffer the tedium for now as it's not so important.

There's no question though meanwhile, that version 1.8 runs it, where the others refuse to.

It's difficult to know what exactly is going on without having access to at least the JREs in question, if not their source.
What i would say, is that even in the 'old days' of stable, backwardly compatible Java, using OS-specific classes would be a dangerous strategy, since they are likely to be volatile. And in a sense, using Java per se for system programming is giving you a mismatch. If you're doing Windows programming, it would be a better fit to use .NET (C# maybe)

I understand your comments, which I don't doubt are correct in many ways; but I am where I am with this, and substituting general doctrine for an actual coding impasse doesn't help explain what has actually changed in the API paradigm - whereever and whatever such a change might consist in.

Looking at the source in the various later versions, java.util.prefs.Preferences doesn't appear to exist. I can only assume I've not got the right idea about the API's organisational architecture, or it's been done away with or refactored in some way to avoid the kind of backdoor coding hack that your latest comment suggests. :)

Whatever the reason, the realignment let's call it is tremendously disappointing, bordering on the contemptuous.

or it's been done away with or refactored in some way to avoid the kind of backdoor coding hack that your latest comment suggests. :)

Almost certainly the first part of your statement is correct. I don't actually understand what your conclusion about backdoor coding means.
My guess is that trying to code against a moving and secret target (the Windows API) has become unsustainable, either for technical or commercial reasons or a combination of both.

I don't actually understand what your conclusion about backdoor coding means.

Well, pejorative for "doing something that the powers that be deem is unacceptable" - either for technical, political, strategic or whatever other reason there may be.

And it may be justifiable. Outside of this particular question of mine though lurks the uneasy feeling that peremptory curtailing of access to processes that are entirely the confection of the coder, is one of the best ways I can think of to stifle innovation and / or examination and testing of interfaces platforms and the wider question of coding altogether.

The 13.0.2 install tells me I have

C:\Program Files\Java\jdk-13.0.2\lib\src.zip\java.prefs\java\util\prefs

inside which reside the Preferences I require. Does anyone have an idea how to import these ?

How does Java resolve the paths to its own libraries anyway ?  For instance how is the import statement able to bring in for example java.util.HashMap  when that's not giving it a full path ?

You must have imported it or it wouldn't compile (unless you're loading the class dynamically). To know exactly what's happening, we need to see the source

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
import java.util.HashMap;
import java.util.Map;
import java.util.ArrayList;
import java.util.List;
import java.util.prefs.Preferences;


  
}

Select allOpen in new window

Looks like the args have been altered - at least the first one - changed from int to long.

Well, as i said, all this is pretty fragile anyway. You'd probably be better off using Runtime.exec with Windows utils

So no ideas as to how to vary that method call to comply with a possible long[] param instead of int[] ?

Well of course you could always deepen your reflection and inspect the state of the available classes/methods