> On 11 Jan 2017, at 07:03, Chris Hegarty wrote:
>
>
> On 01/11/2017 02:55 AM, Paul Sandoz wrote:
>> I am concerned it’s getting too late to twiddle with the security setting so
>> i took the plunge and wrapped the privateLookupIn calls in doPrivileged
>> blocks. It’s ugly but avoids the circ
Hi Peter,
You beat me to it!
My plan was to define a private method, accepting the lookup and teleporting
class, and encapsulating the doPrivileged block. Then i could call that method
for all usages in TLR. It does mean three doPrivileged executions, but that is
probably ok.
Thanks,
Paul.
>
On 01/11/2017 02:55 AM, Paul Sandoz wrote:
> I am concerned it’s getting too late to twiddle with the security setting so
> i took the plunge and wrapped the privateLookupIn calls in doPrivileged
> blocks. It’s ugly but avoids the circularity (JPRT core/hotspot testing has
> not failed).
>
> h
Hi Paul,
On 01/11/2017 02:55 AM, Paul Sandoz wrote:
I am concerned it’s getting too late to twiddle with the security setting so i
took the plunge and wrapped the privateLookupIn calls in doPrivileged blocks.
It’s ugly but avoids the circularity (JPRT core/hotspot testing has not failed).
htt
I am concerned it’s getting too late to twiddle with the security setting so i
took the plunge and wrapped the privateLookupIn calls in doPrivileged blocks.
It’s ugly but avoids the circularity (JPRT core/hotspot testing has not failed).
http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to
On 09/01/2017 19:09, Paul Sandoz wrote:
On 9 Jan 2017, at 05:36, Alan Bateman wrote:
On 05/01/2017 19:01, Paul Sandoz wrote:
Hi,
I encountered some circularity issues with security manager and VarHandles,
specifically when attempting to use the new MethodHandles.privateLookupIn, so
say T
I followed up on my own suggestion and wrote a race-simulating test without
the big hammer:
/**
* Checks that traversal operations collapse a random pattern of
* dead nodes as could normally only occur with a race.
*/
@Test(dataProvider = "traversalActions")
public void
> On 9 Jan 2017, at 13:27, Martin Buchholz wrote:
>
> My whitebox tests tend to use private access only for reading, but I can
> imagine cases where it is useful to give testing code stronger access than
> for regular VarHandles, maybe even to write final fields, for example for
> fuzz testin
On Mon, Jan 9, 2017 at 11:29 AM, Paul Sandoz wrote:
> Hi Martin,
>
> Have you tried using:
>
> MethodHandles.privateLookupIn(ConcurrentLinkedQueue.class,
> MethodHandles.lookup()).
> findVarHandle(…)
>
> ?
>
Thanks! privateLookupIn was not in my toolbox. I'm happy with:
final VarHand
Hi Martin,
Have you tried using:
MethodHandles.privateLookupIn(ConcurrentLinkedQueue.class,
MethodHandles.lookup()).
findVarHandle(…)
?
I agree there is some inconsistency here, and we wanted to discourage the use
of setAccessible. One problem is setAccessible conflates accessibility wit
> On 9 Jan 2017, at 05:36, Alan Bateman wrote:
>
> On 05/01/2017 19:01, Paul Sandoz wrote:
>
>> Hi,
>>
>> I encountered some circularity issues with security manager and VarHandles,
>> specifically when attempting to use the new MethodHandles.privateLookupIn,
>> so say ThreadLocalRandom has
Hi,
It's also inconsistent, because the same type of code works with MethodHandles.
If you make something accessible (and succeed doing this), it uses some special
internal lookup that has no restrictions for unreflect.
Uwe
Am 9. Januar 2017 19:43:44 MEZ schrieb Martin Buchholz :
>Relatedly,
Relatedly, I'm writing whitebox jtreg tests and would like to use
VarHandles to access internal data structures.
Because I have:
* @modules java.base/java.util.concurrent:open
I can use reflection with setAccessible to obtain a usable Field, but if I
try to turn that into a VarHandle I get:
On 05/01/2017 19:01, Paul Sandoz wrote:
Hi,
I encountered some circularity issues with security manager and VarHandles,
specifically when attempting to use the new MethodHandles.privateLookupIn, so
say ThreadLocalRandom has access to fields in Thread [1].
When running with a security manager
Hi,
I encountered some circularity issues with security manager and VarHandles,
specifically when attempting to use the new MethodHandles.privateLookupIn, so
say ThreadLocalRandom has access to fields in Thread [1].
When running with a security manager ThreadLocalRandom clinit depends on
vario
Hi Peter,
> ...so the only way for this to not cause the same problem is for
> Class.reflectionFactory field to be initialized before SecurityManager
> is set.
>
> Was this pure luck and we were just waiting for a situation where this
> was not the case?
I don't know. If you run with -Xlog:class
Hi David,
On 12/26/2016 10:16 PM, David Holmes wrote:
Hi Peter,
I know this is response to the problems with your other recent change,
but this is an enhancement in my opinion, not a bug fix, and the time
for enhancements is passed - though there is still a process to
request them. I do not
On 2016-12-27 02:02, David Holmes wrote:
Hi Claes,
On 27/12/2016 9:48 AM, Claes Redestad wrote:
Hi,
while perhaps an enhancement in isolation, I'll argue this to be a
blocker of or a sub-task of the redo of JDK-8062389 - a P2 bug that
At this stage I would categorise it as one possible way
Hi Claes,
On 27/12/2016 9:48 AM, Claes Redestad wrote:
Hi,
while perhaps an enhancement in isolation, I'll argue this to be a
blocker of or a sub-task of the redo of JDK-8062389 - a P2 bug that
At this stage I would categorise it as one possible way to work around
the issue that JDK-8062389
Hi,
while perhaps an enhancement in isolation, I'll argue this to be a
blocker of or a sub-task of the redo of JDK-8062389 - a P2 bug that
has been long in the making - thus I don't agree that the time for this
has passed, and neither do I think this needs a critical approval
request if it's push
Hi Peter,
I know this is response to the problems with your other recent change,
but this is an enhancement in my opinion, not a bug fix, and the time
for enhancements is passed - though there is still a process to request
them. I do not like to see last minutes changes like this where not
en
On 2016-12-26 21:39, Peter Levart wrote:
Hi Claes,
On 12/26/2016 09:11 PM, Claes Redestad wrote:
Hi,
with strong encapsulation in place this seems perfectly fine to me.
The only downside is that we will lose the extra reminder that the
ReflectionFactory must not escape to untrusted code, bu
Hi Claes,
On 12/26/2016 09:11 PM, Claes Redestad wrote:
Hi,
with strong encapsulation in place this seems perfectly fine to me.
The only downside is that we will lose the extra reminder that the
ReflectionFactory must not escape to untrusted code, but I think we can
all help ensure that doesn'
Hi,
with strong encapsulation in place this seems perfectly fine to me.
The only downside is that we will lose the extra reminder that the
ReflectionFactory must not escape to untrusted code, but I think we can
all help ensure that doesn't happen, right? :-)
Thanks!
/Claes
On 2016-12-26 20:29
Hi,
There are 2 ReflectionFactory classes in JDK 9. The old one is
sun.reflect.ReflectionFactory which ended in jdk.unsupported module and
to which access is restricted with SecurityManager. There is also new
jdk.internal.reflect.ReflectionFactory which is used internally by JDK,
is exported
25 matches
Mail list logo
