[OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in finding class implementing sun.java2d.pipe. RenderingEngine

[Phil Race]

See http://cr.openjdk.java.net/~prr/8038875.2

-phil.

On 05/07/2014 08:21 PM, Phil Race wrote:
> On 5/7/14 5:18 PM, Jim Graham wrote:
>> If they specify something on the command line, and that doesn't 
>> exist, then we end up with Pisces even if Ductus is available.  Is 
>> that intentional?
>
> Well, I decided it was OK as the only people likely to use this were 
> working on
> OpenJDK Pisces improvements so wouldn't be using a build with Ductus 
> anyway
> or were trying to specify pisces instead and spelt it wrong or similar ..
> The fallback behaviour or whether to signal a problem is something that
> could be changed but I expect people who care will be building their own
> anyway so no point in over-engineering this.
>
>>
>> Also, why the switch from "getProperty(, default)" to the basic 
>> getProperty() and manually applying the default?
>
> I changed that in an interim version but it really wasn't needed.
> I'll revert tomorrow.
>
> -phil.
>
>>
>>             ...jim
>>
>> On 5/7/14 11:26 AM, Phil Race wrote:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8038875
>>> http://cr.openjdk.java.net/~prr/8038875/
>>>
>>> This is in support of modularisation (ie jigsaw). After the fix
>>> alternate implementations
>>> are loaded using Class.forName() as specified by the system property
>>> sun.java2d.renderer. Note that only the built-in ones are actually
>>> supported
>>> The mechanism is just for testing.
>>>
>>> BTW since it happens that Oracle JDK includes the pisces classes as 
>>> well
>>> as the closed source ductus I note that its possible to compare the
>>> performance
>>> or other characteristics easily in a closed build which has both by
>>> specifying
>>> to use pisces instead of ductus.
>>>
>>> There's no regression test associated with this. I tested open & closed
>>> builds
>>> (created for all platforms) with standard demos.
>>>
>>> -phil.
>