Patch: issue RT-14177
richard.bair at oracle.com
Fri Jun 1 10:25:03 PDT 2012
I don't think this patch changes anything with regard to those two issues, except for the case where the class referenced by -fx-skin really doesn't exist.
> This should be tested from an applet or with applet-like java.policy, no? I mean, if it's called from user code by way of Control or PopupControl, will it throw a SecurityException?
We're not doing anything now that we weren't doing before. Doesn't the Class.forName handle the security issues when used by an Applet?
> Also, loadSkinClass is a bottle neck and I fear this will make it worse. We may need to think about caching.
I think caching would be a great idea, although I'm not sure it would always be correct (especially when class loaders are taken into account -- you could cache per class loader perhaps but which class loader to cache by?).
In any case, because I loop over the class hierarchy last in the lookup sequence, the only time this will be worse than it is today for existing, working applications is when they are trying to load a skin that doesn't exist. For other apps currently out there, the lookup times will be exactly as they are now (except for the extra method call overhead which, with a JIT at least, is negligible). For Florian, he's going to pay some additional cost as we look up the skin by walking up the hierarchy, but hopefully not much.
More information about the openjfx-dev