OK grand so, will make that change ... thanks Chris
regards
Mark
On 16/06/2016 06:40, Chris Hegarty wrote:
On 15 Jun 2016, at 19:33, Mark Sheppard wrote:
Hi,
please oblige and review the updated webrev:
http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev.01/
I’m happy with the code
> On 15 Jun 2016, at 19:33, Mark Sheppard wrote:
>
> Hi,
> please oblige and review the updated webrev:
>
> http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev.01/
I’m happy with the code changes here.
Trivially, an alternative stylistic option for the method declaration:
private st
thanks Roger ... I'll attend to them
regards
Mark
On 15/06/2016 21:57, Roger Riggs wrote:
Hi Mark,
Thanks for the test cleanup.
In the new security policy files, is it important to enumerate the
individual permissions instead of using AllPermission?
If it is significant, the perhaps a comm
fyi Mark,
The problem running the new test was a bad build on my end, sorry for
the noise.
Roger
On 6/15/2016 4:57 PM, Roger Riggs wrote:
Hi Mark,
Thanks for the test cleanup.
In the new security policy files, is it important to enumerate the
individual permissions instead of using AllPe
Hi Mark,
Thanks for the test cleanup.
In the new security policy files, is it important to enumerate the
individual permissions instead of using AllPermission?
If it is significant, the perhaps a comment is in order, otherwise,
there will be doubt about why the long list instead of the simpler
Hi,
please oblige and review the updated webrev:
http://cr.openjdk.java.net/~msheppar/8146975/jdk9/webrev.01/
http://cr.openjdk.java.net/~msheppar/8146975/jdk9/test/webrev.01/
based on the feedback, the following amendments were made:
the scope of the tests reduced
the removal of the export f
thanks Roger ... will reduce the focus of the test
regards
Mark
On 09/06/2016 15:58, Roger Riggs wrote:
Hi Mark,
With respect to the test, it seems to do a lot more than just be the
test for the current issue.
Perhaps some javadoc in the test could identify the the important
parts of the te
OK I'll look into this again. I'll remove and re check everything.
The reason why is that during the execution of the tests there where
various problems where
there is attempt in java.base to access sun.corba.BridgePermission
at one stage there were failure such as
UnresolvedPermission:
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 l
Hi Mark,
With respect to the test, it seems to do a lot more than just be the
test for the current issue.
Perhaps some javadoc in the test could identify the the important parts
of the test
as opposed to the supporting infrastructure.
If there is more code than is needed for this issue then
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
> On 9 Jun 2016, at 15:18, Roger Riggs wrote:
>
> Hi Mark,
>
> IIOPInputStream.java:
>
> - Does adding doPriv overhead to every field access have a noticeable impact
> on performance?
> If most of the fields are accessible or can easily be checked as being in
> the base module,
> I could s
Oh BTW, I assume the changes to the java.corba module-info are not
needed right? Maybe left over from some debugging?
-Chris.
> On 9 Jun 2016, at 13:35, Chris Hegarty wrote:
>
>
>> On 8 Jun 2016, at 23:18, Mark Sheppard wrote:
>>
>>
>> Hi
>> please oblige and review the following changes
>
Hi Mark,
IIOPInputStream.java:
- Does adding doPriv overhead to every field access have a noticeable
impact on performance?
If most of the fields are accessible or can easily be checked as
being in the base module,
I could see trying the access directly and catching the security
exceptio
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.
> On 8 Jun 2016, at 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.openj
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
17 matches
Mail list logo
