[OpenJDK 2D-Dev] [9] request for review: 8068749: Restrict javax.imageio.spi.ServiceRegistry to ImageIO types

[Stuart Marks]

Hi all,

I still need a second reviewer for this change. Thanks.

s'marks

On 8/3/15 1:49 PM, Phil Race wrote:
> CCC is approved. So I will give this a "+1" .. you just need one other reviewer (if
> you did not get that already) and you can push.
>
> -phil.
>
> On 07/27/2015 07:10 PM, Stuart Marks wrote:
>> Hi all,
>>
>> Please review this following code and API change:
>>
>> Bug:
>>     https://bugs.openjdk.java.net/browse/JDK-8068749
>>
>> Webrev:
>>     http://cr.openjdk.java.net/~smarks/reviews/8068749/webrev.0/
>>
>> The change is to be pushed into the jdk9/client forest.
>>
>> The background is that this is a "preparation for Jigsaw" bug. The
>> javax.imageio.spi.ServiceRegistry class was introduced long ago in order to
>> load Image I/O service providers; in fact it was also fully general service
>> loading mechanism, capable of loading providers for arbitrary service types.
>> This latter function has been superseded by java.util.ServiceLoader
>> (introduced in JDK 6), although iio.SR can still be used for general purpose
>> service provider loading.
>>
>> In JDK 9, Jigsaw modularization will require additional work, and use of new,
>> modular APIs, to implement general purpose service loading. Loading of
>> specific APIs -- which is the primary use case for iio.SR -- is considerably
>> simpler. Given that general purpose service loading is now handled by j.u.SL,
>> we wish to remove general purpose support from iio.SR and restrict its use to
>> loading only Image I/O related service providers.
>>
>> This change adds explicit checks in iio.SR to restrict the service types to
>> the known set of Image I/O interfaces, and it will throw IAE if asked to load
>> a provider for any other service type. Use of iio.SR to load Image I/O
>> providers will continue to work unchanged.
>>
>> This is clearly an incompatible change. I've done some internet searching, and
>> use of iio.SR to load Image I/O providers is quite common. I was able to find
>> one use of iio.SR to load a non Image I/O provider, but the project where this
>> occurred migrated to j.u.SL several years ago. Based on this, we believe the
>> impact of this change to be small.
>>
>> s'marks
>