Patch: issue RT-14177
Kevin Rushforth
kevin.rushforth at oracle.com
Fri Jun 1 11:16:45 PDT 2012
>
> I don't see the security problem because as Richard
> said we don't change the logic run before running the last resort code
Yeah, this makes it very unlikely that there will be any problem. Having
said that, testing that applets still work is good due diligence (and is
required of team integrators before pushing anything into the master).
-- Kevin
Tom Schindl wrote:
> Looks good to me - I don't see the security problem because as Richard
> said we don't change the logic run before running the last resort code
> to use the classloader the classes before us have been loaded with (if
> there would have been a security problem those classes would have failed
> to load already not?).
>
> I think we can live for now with the performance degration in OSGi - the
> other option is even worse.
>
> Thank you very much Richard for taking care of this!
>
> Tom
>
> Am 01.06.12 19:25, schrieb Richard Bair:
>
>> 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.
>>
>> Richard
>>
>>
>
>
>
More information about the openjfx-dev
mailing list