The system property is kind of important, since it allows the value to be overridden at deployment time. Not sure why Sun wouldn't include this feature in their own class, since all of the JDK classes I've seen that use a service provider architecture do support a system property.
I personally don't see a strong reason to use Sun's version, since the Pivot version currently does exactly what we need it to. We have plenty of cases where Pivot features overlap with the JDK - as long as we're not doing something completely redundant, why would we get rid of it? FWIW, none of the XML factories in Java 6 use the ServiceLoader class. I haven't looked into any other possible examples. On Tuesday, May 26, 2009, at 03:22PM, "Todd Volkert" <[email protected]> wrote: >FYI, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4640520 was >the bug that brought Sun's internal implementation to the JDK. I see >that our Service class looks for system properties as well, so it >seems to add some value, but unless there are any strong objections, I >think we should change our Service class to call into the JDK >ServiceLoader when it comes to the META-INF/services facility. > >On Tue, May 26, 2009 at 3:18 PM, Todd Volkert <[email protected]> wrote: >> Reading through the Java service provider interface >> (http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html), I did some >> digging to see why Java hasn't provided the corresponding class, and >> it turns out they have >> (http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html)! >> So the question is: what does pivot.util.Service provide that >> java.util.ServiceLoader doesn't? And can the META-INF/services >> portion of pivot.util.Service be made to use java.util.ServiceLoader? >> The JDK version supports the full spec, including correct handling of >> comments, whereas ours doesn't. This all came about because we should >> add a license header to our service provider configuration files, but >> right now, that chokes our parser :-( >> >> -T >> > >
