Repository navigation
JarLoader breaks strong encapsulation of JDK classes #10
Description
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.
Activity
markusthoemmes commentedon Feb 20, 2018
@marschall thanks for the notification and analysis of the issue. Sounds like we should fix that. Got an alternative approach on your mind?
marschall commentedon Feb 20, 2018
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 aMapin tests andSystem.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_DEADLINEas simulated environment variables. You'll have to find a different way in your programming model to access this configuration.rabbah commentedon Feb 20, 2018
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,
whiskobject in node runtime was an example of this... and we stripped that out in favor of the env vars.