JarLoader breaks strong encapsulation of JDK classes about openwhisk-runtime-java HOT 3 OPEN

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

from openwhisk-runtime-java.

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.

from openwhisk-runtime-java.

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.

from openwhisk-runtime-java.