JarLoader breaks strong encapsulation of JDK classes

[marschall]

JarLoader#augmentEnv performs illegal access on core JDK classes by breaking accessibility rules. This breaks the strong encapsulation rules outlined in JEP 261. Starting with Java 9 this will print a warning by default on the command line (and possibly have a performance and runtime impact). At some yet to be defined point in the future this will throw an exception by default. At some later yet to be defined point in the future this will always throw an exception.

I don't see an alternative to entirely moving away from modifying environment variables. They are readonly in Java. Modifying them is a hack that makes testing hard and multi threading impossible.

[markusthoemmes]

@marschall thanks for the notification and analysis of the issue. Sounds like we should fix that. Got an alternative approach on your mind?

[marschall]

It's though, I know because we have an internal project that has the same issue 😞
What we decided to do is that code has to stop using System.getenv() and instead use an abstraction that can use a Map in tests and System.getenv() in production.

For you it may be a bit more complicated. Ultimately you can't have __OW_API_KEY, __OW_NAMESPACE, __OW_ACTION_NAME, __OW_ACTIVATION_ID, __OW_DEADLINE as simulated environment variables. You'll have to find a different way in your programming model to access this configuration.

[rabbah]

We can, for java, provide a singleton object with the fields. It would deviate from the other runtimes but perhaps not so bad as we can then maybe even provide a richer interface. I haven't researched a new solution myself, the caveat with these values is that they're dynamic during the "run", not "init" when the env vars are first defined.

Edit: I know, whisk object in node runtime was an example of this... and we stripped that out in favor of the env vars.