-
Bug
-
Resolution: Fixed
-
P4
-
None
Currently when using the User JVM Preferences the user has to know the particulars of how the magic values for the preference node are and where to use the java preferences api.
We should provide a simple class with three static methods. One that returns a Map<String, String> of the current User JVM preferences, one that when passed in a Map<String, String> will write those values to the user jam preferences, and a method that returns a List<String> of the suer JVM options that the launcher will be examining for user jvm values. How the launcher stores and retrieves those values is opaque to the end user, and in fact allows us to provide different store mechanisms.
What needs to be determined is what jar these classes will live in and how those will be made available to a runtime class.
I propose deploy.jar, and that it will always be brought in if the javaruntime the self-contained-applicaiton will be using contains it. This is the current practice for including the jar anyway, so no more magic would need to be written. I am open to other suggestions and this one is provided just to get the ball rolling.
We should provide a simple class with three static methods. One that returns a Map<String, String> of the current User JVM preferences, one that when passed in a Map<String, String> will write those values to the user jam preferences, and a method that returns a List<String> of the suer JVM options that the launcher will be examining for user jvm values. How the launcher stores and retrieves those values is opaque to the end user, and in fact allows us to provide different store mechanisms.
What needs to be determined is what jar these classes will live in and how those will be made available to a runtime class.
I propose deploy.jar, and that it will always be brought in if the javaruntime the self-contained-applicaiton will be using contains it. This is the current practice for including the jar anyway, so no more magic would need to be written. I am open to other suggestions and this one is provided just to get the ball rolling.
- relates to
-
JDK-8098228 Umbrella for Changes for JEP-208 - Java Packager Improvements
- Resolved