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.
