On 25/05/15 09:42, Erik Joelsson wrote:
On 2015-05-22 18:53, Mandy Chung wrote:
On 05/22/2015 08:09 AM, Alan Bateman wrote:
On 22/05/2015 13:55, Chris Hegarty wrote:
:
I think it could be done either way.
Valerie - have you considered not pushing the services configuration
files with this change? With the change then the java.security
configuration is still class names, not provider names, so the
fallback should just work. This is what we've done in a few other
areas (like JNDI for example).
I wasn't aware of the other areas that move to service provider but
remain being loaded with the fallback Class.forName.
URL protocol handlers, and JDNI initial context, fall back to
Class.forName for built-in handlers/implementations, and do not expose
the implementation as services.
I would prefer java.security should convert to use the provider names
as an example and also exercise the code path using service
I think URL protocol handlers works well as an example too. It is a
minimal new service type, easy to understand. You can write your own Foo
handler in a few lines of code.
providers. If this causes much work to workaround it temporarily, I
won't object the security providers are not truly service providers
(no META-INF/services and java.security lists class name instead)
Another option to workaround this:
we only need to merge the service config files for generating the
image. Can we have do the concatenation of
jdk/modules/*/META-INF/services file and output to
supports/image_gensrc before the images target and have the image
builder to exclude all jdk/modules/*/META-INF/services files and take
the supports/image_gensrc instead?
This will remove the process-provider logic from Gensrc-*.gmk files.
Would this be a better alternative?
Maybe, I'm not sure. I still think solving this in java code in the
ImageBuilder is the right thing to do.
If it is agreed that these files are needed, then I can look at
expanding the ImageBuilder to do concatenate them.
-Chris.
/Erik
