jndn

On my machine, the use of SecureRandom blocks for 16 seconds while it waits for enough entropy to generate a seed. After talking to Jeff, a utility method to set a custom random number generator would be useful when using jndn during testing; by default, SecureRandom should be returned.

Put in a PR to help out; not very complex but one thing you may want to think about is that now any user with access to jndn can change the RNG for the system...

I assume you mean that applications which use the same shared jar file can change the RNG?

Why not using Java's system properties? The same way java.logging is configured?

A question about how the Java run time works for a normal static variable: If two different applications load the same jNDN jar file, and one sets a static class variable, will the other application see the change? Or does the run time keep separate copies of static variable for different applications? (Gosh I hope so.)

Jeff Thompson wrote:

I assume you mean that applications which use the same shared jar file can change the RNG?

Yes

Alex Afanasyev wrote:

Why not using Java's system properties? The same way java.logging is configured?

It's not just choosing between Random and SecureRandom, a user may also want to setSeed(...) or use their own RNG

Jeff Thompson wrote:

A question about how the Java run time works for a normal static variable: If two different applications load the same jNDN jar file, and one sets a static class variable, will the other application see the change? Or does the run time keep separate copies of static variable for different applications? (Gosh I hope so.)

My understanding is that different JVMs have different static references; separate process, separate memory space. By "RNG for the system" up above I really meant "RNG for the application that is using the jndn JAR"

Why not using Java's system properties? The same way java.logging is configured?

It's not just choosing between Random and SecureRandom, a user may also want to setSeed(...) or use their own RNG

Even this requirement doesn't preclude use of system properties. With java, one can create object using class name as a string and example of this is java.util.logging.config.class configuration. With this, one can specify random class or have custom randomization class that sets whatever seed inside the constructor.

Why not using Java's system properties? The same way java.logging is configured?

It's not just choosing between Random and SecureRandom, a user may also want to setSeed(...) or use their own RNG

Even this requirement doesn't preclude use of system properties. With java, one can create object using class name as a string and example of this is java.util.logging.config.class configuration. With this, one can specify random class or have custom randomization class that sets whatever seed inside the constructor.

Correct, but why expose something as configuration when the only requirement is programmatic? If I create MyEvenBetterRandom() with methods setSeed(), setSeedUsingSolarPower(), and setSeedWhileEatingHam(), now I have to expose configuration properties for all of those. It seems like that approach requires more code.

If you're suggesting that the Java properties protect from changing the RNG during runtime, why not just add a check in setRandom() that only allows the RNG to be set once?

On what are you going to call "setRandom"? RNG can be used in many different places in the library (actually, I'm not sure which place you're referring originally), making it difficult to track all those places.

What I'm saying is just it feels that system configuration is better place to do such system-wide setting (e.g., configured somewhere in application's .jar).

Alex Afanasyev wrote:

On what are you going to call "setRandom"? RNG can be used in many different places in the library (actually, I'm not sure which place you're referring originally), making it difficult to track all those places.

What I'm saying is just it feels that system configuration is better place to do such system-wide setting (e.g., configured somewhere in application's .jar).

I hear what you're saying; take a look at https://github.com/named-data/jndn/pull/9 and see if calling setRandom() in the first line of your application would be equivalent.

What is "first line" of my application? Not all apps start with main(). Android app can start from wherever class. Anyhow, it doesn't really affect me at the moment. I just feel that Java predominantly relies on various .properties files to do "deployment" customizations. It doesn't preclude having explicit setter API.