Hi Roger,
I don't know whether the performance of invoking
sun.reflect.ReflactionFactory methods matters very much, but you could
do a nit to help JIT optimize their invocation better. As both
jdk.internal.reflect.ReflectionFactory and the
sun.reflect.ReflectionFactory are singletons, you cou
On 21/10/2016 08:08, Peter Levart wrote:
:
Otherwise I think it is a good strategy to give frameworks limited
access to selected private methods targeted for a special purpose -
serialization in this case, instead of opening the doors for generic
reflection (via setAccessible). It just feels
Roger,
On 20/10/16 18:57, Roger Riggs wrote:
Hi,
Thanks for the comments..
Webrev's updated in place with comments so far. (Including David's and
Amy's)
http://cr.openjdk.java.net/~rriggs/webrev-reflection-factory-8164908/
This looks very good Roger. A few very minor comments:
1) The exp
Hi Peter,
Thanks for the review and suggestions.
Will update the webrev shortly.
On 10/21/2016 3:08 AM, Peter Levart wrote:
Hi Roger,
I don't know whether the performance of invoking
sun.reflect.ReflactionFactory methods matters very much, but you could
do a nit to help JIT optimize their i
Hi Chris,
On 10/21/2016 6:36 AM, Chris Hegarty wrote:
Roger,
On 20/10/16 18:57, Roger Riggs wrote:
Hi,
Thanks for the comments..
Webrev's updated in place with comments so far. (Including David's and
Amy's)
http://cr.openjdk.java.net/~rriggs/webrev-reflection-factory-8164908/
This looks
Any feedback on this? I'm really interested in implementing such
BufferedReader/BufferedStreamReader to allow speeding up my applications
without having to think in an asynchronous way or multi-threading while
programming with it.
That's why I'm asking this here.
On 13/10/2016 14:45, Brunoai
Off the top of my head, I would say it's not possible to change the design of an
_extensible_ type that has been out there for 20 or so years. All these I/O
streams from java.io were designed for simple synchronous use case.
It's not that their design is flawed in some way, it's that they doesn't
Please review a test correction to the permissions granted to the test
and the check that the global filter cannot be re-set if once set.
Removed unnecessary code supplying a OIS when testing setting the global
filter.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-filtertest-8167192/
Th
Looks OK Roger
Best
Lance
> On Oct 21, 2016, at 1:16 PM, Roger Riggs wrote:
>
> Please review a test correction to the permissions granted to the test
> and the check that the global filter cannot be re-set if once set.
> Removed unnecessary code supplying a OIS when testing setting the global
Hi Pavel,
I think Brunoais asking for a double buffering scheme in which the
implementation of
BufferReader fills (a second buffer) in parallel with the application
reading from the 1st buffer
and managing the swaps and async reads transparently.
It would not change the API but would change th
Pavel is right.
In reality, I was expecting such BufferedReader to use only a single
buffer and have that Buffer being filled asynchronously, not in a
different Thread.
Additionally, I don't have the intention of having a larger buffer than
before unless stated through the API (the constructor
Hi Max,
Looks ok.
An additional reviewer would be good too.
Roger
On 10/20/2016 4:51 AM, Wang Weijun wrote:
Please review the code change at
http://cr.openjdk.java.net/~weijun/8167646/webrev.00/
A new flag invalid is added so invalid FilePermissions (invalid Path) do not
equal or imply
Just to append to my previous email. BufferedReader wraps any Reader out there.
Not specifically FileReader. While you're talking about the case of effective
reading from a file.
I guess there's one existing possibility to provide exactly what you need (as I
understand it) under this method:
/**
OK. Will do.
On 21/10/2016 19:21, Pavel Rappo wrote:
Just to append to my previous email. BufferedReader wraps any Reader out there.
Not specifically FileReader. While you're talking about the case of effective
reading from a file.
I guess there's one existing possibility to provide exactly wh
It would be useful for processes which self-update or otherwise
self-manage to be able to exec a new process which replaces the current
one, in the manner of POSIX execve. This might tie in with
ProcessBuilder, though there are a few key differences:
1. The method to execute the process (obvi
Historically, this was thought to be not an option because Windows doesn't
have exec (or fork).
Cygwin's emulation of fork does create a windows subprocess, I believe.
The desire to have clean shutdown of the Java process does make things more
interesting as well, as you point out.
One use case i
On Tue, Oct 18, 2016 at 4:18 PM, Martin Buchholz
wrote:
>
>
> On Tue, Oct 18, 2016 at 4:00 PM, Vitaly Davidovich
> wrote:
>
>>
>>> > * Change in allocation/capacity policy.
>>> >
>>> > The removal of the power-of-two restriction, and applying a 1.5x growth
>>> > factor (same as ArrayList) seems
Dear Mr. Peter Levart:
http://cr.openjdk.java.net/~plevart/jdk9-dev/6378384_Reflection.ensureAccess/webrev.04/
+1. Ship it! Thanks for compressing it!
Thanks for reviewing. Pushed.
Thank you very much. 6378384 was submitted by me.
Is your fix is included? By using JDK 9-ea+140-jigsaw, the
18 matches
Mail list logo
