[OpenJDK 2D-Dev] [9] request for review: 8068749: Restrict javax.imageio.spi.ServiceRegistry to ImageIO types
Phil Race
philip.race at oracle.com
Mon Aug 3 20:49:04 UTC 2015
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
More information about the 2d-dev
mailing list