Hi,
Please review this tiny update, that puts @since 9 tags over new Indify
String Concat JDK APIs:
http://cr.openjdk.java.net/~shade/8148730/webrev.01/
Cheers,
-Aleksey
Hi Sherman and all,
Could you please let know your thought and the past case about AES?
Thanks,
Yuji
2016-01-08 0:01 GMT+09:00 KUBOTA Yuji :
> Hi Sherman,
>
> Thank you for sharing!
>
> 2016-01-07 4:04 GMT+09:00 Xueming Shen :
>> The reason that I'm not convinced that we really need a public in
Hi Roger,
Looks good to me - but I'd suggest to call fullGC at least once
before waiting on the semaphore (e.g. add a call to whitebox.fullGC()
when entering checkCleaned() before line 285).
That might maximize the chances that the referred object will be
GC'ed before you start waiting on the sem
Hi Aleksej,
is it really needed to add the "@since 9" tag to the
methods/constructors when the whole class is since JDK 9? As far as I
know the @since tag should be only added to class members introduced
in a later version than the class.
Best regards,
Andrej Golovnin
On Mon, Feb 1, 2016 at 10:2
Hi,
I don't know, you tell me -- you have the tools that enforce
@since-ness! Certainly, we can put @since on classes only, if that is
acceptable.
-Aleksey
On 02/01/2016 12:32 PM, Andrej Golovnin wrote:
> Hi Aleksej,
>
> is it really needed to add the "@since 9" tag to the
> methods/constructor
On 01/02/2016 09:35, Aleksey Shipilev wrote:
Hi,
I don't know, you tell me -- you have the tools that enforce
@since-ness! Certainly, we can put @since on classes only, if that is
acceptable.
-Aleksey
@since 9 on the class should be sufficient here. If it becomes necessary
to add methods in
Hi Aleksej,
> I don't know, you tell me -- you have the tools that enforce
> @since-ness! Certainly, we can put @since on classes only, if that is
> acceptable.
I don't have such tools. But when I write JavaDocs I try to follow the
recommendations from this article:
http://www.oracle.com/technet
On 02/01/2016 12:44 PM, Andrej Golovnin wrote:
>> I don't know, you tell me -- you have the tools that enforce
>> @since-ness! Certainly, we can put @since on classes only, if that is
>> acceptable.
>
> I don't have such tools.
Apologies, I confused you with another Andrey :)
Sure, let's do cla
On 01/02/2016 09:56, Aleksey Shipilev wrote:
:
Sure, let's do class-only:
http://cr.openjdk.java.net/~shade/8148730/webrev.02/
Looks good.
> Apologies, I confused you with another Andrey :)
>
> Sure, let's do class-only:
> http://cr.openjdk.java.net/~shade/8148730/webrev.02/
No problem, Aleksey. Looks much better now. :)
Best regards,
Andrej Golovnin
On 02/01/2016 01:03 PM, Alan Bateman wrote:
> On 01/02/2016 09:56, Aleksey Shipilev wrote:
>> :
>>
>> Sure, let's do class-only:
>>http://cr.openjdk.java.net/~shade/8148730/webrev.02/
>>
> Looks good.
Thanks guys, pushed.
-Aleksey
Hi Daniel,
On 2/1/2016 4:24 AM, Daniel Fuchs wrote:
Hi Roger,
Looks good to me - but I'd suggest to call fullGC at least once
before waiting on the semaphore (e.g. add a call to whitebox.fullGC()
when entering checkCleaned() before line 285).
That might maximize the chances that the referred ob
On 01/02/16 15:47, Roger Riggs wrote:
The number of cycles was scaled by the timeoutFactor but it is more
intuitive to
scale the timeout itself.
checkCleaned is invoked for cases where the cleanup function will not be
called
so increasing the timeout will just increase the running time of the te
Please review an API addition to handle signals such as SIGINT, SIGHUP,
and SIGTERM.
This JEP 260 motivated alternative to sun.misc.Signal supports the use
case for
interactive applications that need to handle Control-C and other signals.
The new java.util.Signal class provides a settable prima
Please review a test improvement to address an intermittent test failure in
the java.time System Clock test for microsecond support.
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-micros-8143016/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8143016
Thanks, Roger
Looks OK Roger.
On Feb 1, 2016, at 11:41 AM, Roger Riggs wrote:
> Please review a test improvement to address an intermittent test failure in
> the java.time System Clock test for microsecond support.
>
> webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-micros-8143016/
>
> Issue:
> https:/
Thank you for taking this on Roger.
An initial question to help my understanding. [ I think I need to
understand this, before I can comment further on the API ]
I'm a little confused about how the default handler is supposed to
work, so I looked at the implementation and become even more confuse
Fine by me
Stephen
On 1 February 2016 at 16:41, Roger Riggs wrote:
> Please review a test improvement to address an intermittent test failure in
> the java.time System Clock test for microsecond support.
>
> webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-micros-8143016/
>
> Issue:
> http
> On Jan 30, 2016, at 12:00 AM, Alan Bateman wrote:
>
>
> On 29/01/2016 17:39, Paul Sandoz wrote:
>> :
>> Alan’s point is that traversing using entries()/stream() always returns the
>> versioned entries (if any) rather than all entries, thus in a sense filters.
>>
>> My assumption was the tra
After much debate on what to do when CompleteableFuture.whenComplete
encounters an exception in both the source and the action, we chose
what was acceptable to the most people - add the action's exception to
the source exception as a suppressed exception. And added usage
guidelines. And gave hand
hi Roger,
I love that we are adding this Signal object. I have several questions, but
please do not take them as criticism, I’m just seeking clarification and
providing feedback:
#1 Re: "Consumers for signals that are unknown or reserved by the Java
implementation can not be registered.”
- W
Hi Chris,
On 2/1/2016 11:47 AM, Chris Hegarty wrote:
Thank you for taking this on Roger.
An initial question to help my understanding. [ I think I need to
understand this, before I can comment further on the API ]
I'm a little confused about how the default handler is supposed to
work, so I lo
On 02/01/2016 09:58 AM, Steve Drach wrote:
On Jan 30, 2016, at 12:00 AM, Alan Bateman wrote:
On 29/01/2016 17:39, Paul Sandoz wrote:
:
Alan’s point is that traversing using entries()/stream() always returns the
versioned entries (if any) rather than all entries, thus in a sense filters.
My
Hi Gerard,
On 2/1/2016 1:58 PM, Gerard Ziemski wrote:
hi Roger,
I love that we are adding this Signal object. I have several questions, but
please do not take them as criticism, I’m just seeking clarification and
providing feedback:
#1 Re: "Consumers for signals that are unknown or reserved
Hi,
Please review the fix for a corner case in StringConcatFactory exactness
check, which produces invalid bytecode:
https://bugs.openjdk.java.net/browse/JDK-8148787
Note that this happens when all three things align:
a) BSM is called directly, as Java method -- javac would never produce
such
Alan’s point is that traversing using entries()/stream() always returns
the versioned entries (if any) rather than all entries, thus in a sense
filters.
My assumption was the traversal should by default be consistent with a
calls to getEntry, thus:
jarF
> On Feb 1, 2016, at 1:25 PM, Roger Riggs wrote:
>
> Hi Gerard,
>
> On 2/1/2016 1:58 PM, Gerard Ziemski wrote:
>> hi Roger,
>>
>> I love that we are adding this Signal object. I have several questions, but
>> please do not take them as criticism, I’m just seeking clarification and
>> providi
Hi,
I discovered a flaw in the fix; it needs to re-read the instant from the
clock inside the inner loop.
Please review.
Thanks, Roger
On 2/1/2016 11:41 AM, Roger Riggs wrote:
Please review a test improvement to address an intermittent test
failure in
the java.time System Clock test for mic
I’m sorry, I didn’t look at the code close enough before I started talking ;-)
Right now entries()/stream() returns all entries and if the JarFile is
constructed with a Release object != Release.BASE, the base entries that are
returned are the versioned entries. I think this behavior is a bit
Hi,
On 2/1/2016 3:17 PM, Gerard Ziemski wrote:
On Feb 1, 2016, at 1:25 PM, Roger Riggs wrote:
Hi Gerard,
On 2/1/2016 1:58 PM, Gerard Ziemski wrote:
hi Roger,
I love that we are adding this Signal object. I have several questions, but
please do not take them as criticism, I’m just seeking c
I believe the answer should be based on your viewpoint of what "is" a JAR.
Do you consider the JAR to be a dumb ZIP container or an artifact of the
Java runtime? If it's the former, then return everything because the
version folder is meaningless in this perspective. Otherwise, treat the JAR
accord
See the change, looks OK
On Feb 1, 2016, at 3:26 PM, Roger Riggs wrote:
> Hi,
>
> I discovered a flaw in the fix; it needs to re-read the instant from the
> clock inside the inner loop.
> Please review.
>
> Thanks, Roger
>
> On 2/1/2016 11:41 AM, Roger Riggs wrote:
>> Please review a test im
Hi Roger,
Sorry I couldn't look into the code in extreme detail right now but
would like to clarify the big picture ...
Can you please clarify the exact flow of control from when a signal is
sent to the process and when the Java handler for it gets to run - what
is handled by which thread wh
HI David,
On 2/1/2016 4:26 PM, David Holmes wrote:
Hi Roger,
Sorry I couldn't look into the code in extreme detail right now but
would like to clarify the big picture ...
Can you please clarify the exact flow of control from when a signal is
sent to the process and when the Java handler fo
> On Jan 31, 2016, at 4:19 AM, Peter Levart wrote:
>
> Hi Kim,
Hi Peter - Thanks for looking at this.
> This change will make it practically impossible to miss the enqueued
> references.
Good. That’s the goal.
> But this could be an opportunity to also clean-up the code a bit. The
> checkR
Hi Roger,
On 2/02/2016 7:41 AM, Roger Riggs wrote:
HI David,
On 2/1/2016 4:26 PM, David Holmes wrote:
Hi Roger,
Sorry I couldn't look into the code in extreme detail right now but
would like to clarify the big picture ...
Can you please clarify the exact flow of control from when a signal i
Hi, Hong.
Thanks again for looking closely at the regular expression and providing
comments.
> - The outer most quantifier in (((\.0)*\.[1-9][0-9]*)*)* is redundant
> and a source of catastrophic backtracking. You only need
> ((\.0)*\.[1-9][0-9]*)*.
> - The outside - in PRE part (\-([a-zA-Z0
Hello!
IG> It's misfortune that the spec of subList() doesn't match the spec of
IG> similar methods, like CharSequence.subSequence() or String.substring().
IG> It even contradicts the spec of List.subList(), which declares only IOOB
IG> to be thrown!
Yes, it's a pity. Isn't it the reason to chang
Thanks Tagir for the comments!
On 02.02.2016 9:19, Tagir F. Valeev wrote:
Hello!
IG> It's misfortune that the spec of subList() doesn't match the spec of
IG> similar methods, like CharSequence.subSequence() or String.substring().
IG> It even contradicts the spec of List.subList(), which declar
On Mon, Feb 1, 2016 at 10:19 PM, Tagir F. Valeev wrote:
> I have a doubt about replacing rangeCheckForAdd. What if size() ==
> Integer.MAX_VALUE? This is not an issue for ArrayList as it's limited
> by MAX_ARRAY_SIZE which is Integer.MAX_VALUE - 8.
Actually, the limit is Integer.MAX_VALUE. But
Anyone? This looks like a trivial fix.
-Aleksey
On 02/01/2016 10:47 PM, Aleksey Shipilev wrote:
> Hi,
>
> Please review the fix for a corner case in StringConcatFactory exactness
> check, which produces invalid bytecode:
> https://bugs.openjdk.java.net/browse/JDK-8148787
>
> Note that this ha
Dear Iris,
On closer look, there seems to be some conflicting definition of version string.
In JEP: http://openjdk.java.net/jeps/223
$VNUM(-$PRE)?(\+$BUILD)?(-$OPT)?
In Javadoc:
http://cr.openjdk.java.net/~iris/verona/8072379/doc.3/jdk/Version.html
$VNUM(-$PRE)?(\+($BUILD)?(-$OPT)?)?
In implem
42 matches
Mail list logo
