RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Mark Sheppard mark.sheppard at oracle.com
Thu Jun 9 14:49:43 UTC 2016


Hi Chris,

thanks for the feedback

yes, that's correct the granting of the all permissions to corba, allows 
this solution to work.
Without all permission the RuntimePermission accessDeclaredField is 
needed and the doPrivilege is redundant, but
the module-info export is needed.

It is possible to reduce the test to a scenario which  uses Test3 and 
Test4 classes only, as they emulate those
used in the customer application which triggered the problem.

regards
Mark

On 09/06/2016 13:35, Chris Hegarty wrote:
>> On 8 Jun 2016, at 23:18, Mark Sheppard <mark.sheppard at oracle.com> wrote:
>>
>>
>> Hi
>>    please oblige and review the following changes
>> http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev/
>>
>> http://cr.openjdk.java.net/~msheppar/8146975/jdk9/test/webrev/
>>
>> which address the issue raised in
>> https://bugs.openjdk.java.net/browse/JDK-8146975
>>
>> the type checking in inputClassFields and other places failed to fully allowing for
>> the processing of return ValueTypes, and hence the getDeclaredField fails as
>> "application code" exist  on the call stack restricting access. This leads to a security exception,
>> which in turn leads to an IllegalArgumentExcetption, the processing of which failed to allow
>> for a null object value in the stream.
>> This has now been rectified, with the getDeclaredField wrapped in a doPrivileged call.
> This works because the java.corba module is granted all permissions. If this
> was to ever change then I assume it would require RuntimePermission(
> "accessDeclaredMembers”).
>
> The changes look ok to me.  Wow, that is some test! I assume it cannot easily
> be reduced.
>
> -Chris.
>
>> regards
>> Mark



More information about the core-libs-dev mailing list