RFR: JDK-8146975 - NullPointerException in IIOPInputStream.inputClassFields

Mark Sheppard mark.sheppard at oracle.com
Thu Jun 9 15:05:53 UTC 2016


Thanks Sean, I'll incorporate your amendments

wrt static ports, it is a problems, but for these test one that is 
unavoidable

ConcurrentHashMapTest incurs intermittent failures due to port already 
in use issue.
I'll make a change for a bug against this, in the near future,  to 
overcome and lessen the probability of
its occurrence.

regards
Mark

On 09/06/2016 13:57, Seán Coffey wrote:
>
> Hey Mark,
>
> Looks fine. A few comments.
>
>> 2291                     Class<?> declaredFieldClass = declaredClassField.getType();
>> 2292
>> 2293                     if (declaredFieldClass == null) {
>> 2294                             continue;
>> 2295                     }
> I'm not sure if this check is required. Can getType() return null ?
>
> ==
>
>> 2833                         Field classField;
>> 2834                         classField = c
>> 2835                                 .getDeclaredField(fieldName);
>> 2836                         return classField;
> Could we fold that code down to 'return c.getDeclaredField(fieldName);' ?
>
> For the tests :
> ==
> ConcurrentHashMapTest.java :
> you might want to remove the old rmiServerProcess.destroy(), 
> orbdProcess.destroyForcibly() comments.
> ==
> HelloClient.java
> line 157 : s/1000/ONE_SECOND
>
> The use of static ports could be one to watch. If we encounter port 
> issues, the test might have to be revisited.
> Regards,
> Sean.
> On 08/06/2016 23:18, Mark Sheppard 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.
>>
>> regards
>> Mark
>



More information about the core-libs-dev mailing list