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.
