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

[Sergey Bylokhov]

The fix looks fine. Thanks.

On 12.08.15 19:51, Stuart Marks wrote:
> 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
>>


-- 
Best regards, Sergey.