Nowadays whenever we introduce a new security-related property, we are thinking about whether it can also be both a system property and a security property. If so, it can be set "permanently" in conf/security/java.security or "temporarily" as a system property. See https://hg.openjdk.java.net/jdk/jdk/file/d488477865c0/src/java.base/share/classes/sun/security/util/SecurityProperties.java#l45.
--Max > On Nov 30, 2018, at 12:44 AM, Nico Williams <nico.willi...@twosigma.com> > wrote: > > On Thu, Nov 29, 2018 at 10:00:02AM +0800, Weijun Wang wrote: >>> - If you can get Legal approval for including / distributing a fork of >>> Martin Rex's bridge, you'll get all of the above functionality and >>> also acceptor functionality. >> >> Anyway, one can use his bridge with -Dsun.security.jgss.lib. > > Oh, speaking of this, we wanted to be able to use the registry for this > so our users don't have to specify the -Dsun.security.jgss.lib on the > command-line. The JDK does have a generic interface to the registry, > the Preferences interface and its implementations, but because some > implementations have support for remote stores, it depends on all of > security/ being built first, which means I couldn't use it :/ > > There are places where there is native C/C++ code to use the registry > because of this, and I thought of copying that pattern. But I never got > around to doing that. > > It'd be nice if Preferences, or a cut-down version for private in-JDK > use, supported access to local prefs from security components of the > JDK. I'm not entirely sure how to make that happen, but it would be a > good project for someone, I'm sure :) > > Nico > --
