[OpenJDK 2D-Dev] RFR: 8038875: Remove use of ServiceLoader in finding class implementing sun.java2d.pipe. RenderingEngine
mandy.chung at oracle.com
Wed May 7 19:26:41 UTC 2014
On 5/7/2014 11:26 AM, Phil Race wrote:
Thanks for taking this on. I have some minor comments:
line 129: if sun.java2d.renderer is set, it finds a custom
RenderingEngine from the bootclasspath (as the current class loader is
the bootstrap class loader). On the other hand, in the original
implementation, the service loader loads from the extension class
loader. I'm not proposing to use a different class loader since this is
not a supported way to plugin a custom rendering engine. Just to mention
it to call out the difference.
You may consider to use the 3-arg version of Class.forName and not to
initialize the class. This is called within a doPrivileged block and
it's generally a good convention to invoke the class initialization of
the specified class (from the system property) outside the doPrivileged
block. Static analysis tool may consider catching the 1-arg version of
Class.forName and flag it as a warning.
line 134-140: PiscesRenderingEngine is always present, right? Would it
be better just to return "new PiscesRenderingEngine()"?
otherwise, looks good.
> 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
> 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
> or other characteristics easily in a closed build which has both by
> 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.
More information about the 2d-dev