Review request for JDK-8139435: Make sure CallSiteDescriptor.getLookup is subject to a security check

[Attila Szegedi]

> On Oct 16, 2015, at 5:11 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> What's the rationale for providing the static lookupEquals and lookupHashCode  methods in AbstractCallSiteDescriptor instead of just putting the code in non-abstract instance methods? This way it's a bit more flexible, but I'm not sure it warrants the additional API surface.

I agree that the API surface increase is not great. The idea was to externalize into subclasses anything that needs access to the lookup object instead of providing access to the lookup object in a superclass. But in the end, that’s actually a better idea (as Sundar pointed out). Fortunately, another changeset coming soon will fix this by making CallSiteDescriptor into a class instead of an interface, and then reduce the API surface back (and eventually eliminate all subclasses and just leave CallSiteDescriptor).

> There are references to the old getTarget(Lookup) method in the javadoc comments of CallerSensitiveDynamicMethod.java and SimpleDynamicMethod.java that should be changed to getTarget( CallSiteDescriptor).

Fixed the JavaDoc comments, thanks.


Attila.

> 
> +1
> 
> Hannes
> 
> 
> Am 2015-10-14 um 15:30 schrieb Attila Szegedi:
>> Please review JDK-8139435 "Make sure CallSiteDescriptor.getLookup is subject to a security check" at <http://cr.openjdk.java.net/~attila/8139435/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8139435>
>> 
>> Notes:
>> - webrev also shows a previous issue in the history of some of the files, but the changes for that issue are not in the diffs.
>> - the mechanism for security checks in this changeset is sound, but it is even further improved by making CallSiteDescriptor into a proper class and internalizing the checks later on (I will be sending that changeset for review separately later).
>> 
>> Thanks,
>>   Attila.
>