http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html
> 40 lines changed: 17 ins; 2 del; 21 mod;
Hi all,
could you please review this small patch which moves tests from test/jdk/vm?
there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are
hotspot tests, so they
Hi Naoto,
The fix looks fine.
The direction for new tests is to give them functional names, not bugids.
Is there a suitable name?
CalendarDataUtility.java: 260; the assert is just documentation right?
Its rare to see asserts enabled except in test contexts.
Thanks, Roger
On 2/20/19 5:54
On 20/02/2019 11:33, Andrew Haley wrote:
> On 2/20/19 11:28 AM, Andrew Dinn wrote:
>> So, in the next webrev when force() with no args is called on a non-SYNC
>> mode buffer I will ensure it continues to call
>>
>> force0(fd, mappingAddress(offset), mappingLength(offset))
>>
>> For a SYNC
with my ASM hat,
- Mail original -
> De: "Lindenmaier, Goetz"
> À: "Peter Levart" , "Roger Riggs"
> , "core-libs-dev"
>
> Cc: hotspot-runtime-...@openjdk.java.net
> Envoyé: Mardi 19 Février 2019 17:08:07
> Objet: RE: RFR(L): 8218628: Add detailed message to NullPointerException
>
On 2/20/19 11:28 AM, Andrew Dinn wrote:
> So, in the next webrev when force() with no args is called on a non-SYNC
> mode buffer I will ensure it continues to call
>
> force0(fd, mappingAddress(offset), mappingLength(offset))
>
> For a SYNC buffer I'll redirect to call
>
> force(0, limit())
Thanks Naoto San and Sean for review. I have incorporate all the comments.
Please find below updated version of webrev :-
http://cr.openjdk.java.net/~rpatil/JapaneseEra_changes_11u/webrev.01/
Regards,
Deepak
-Original Message-
From: Naoto Sato
Sent: Tuesday, February 19, 2019 10:23 PM
On 2/20/2019 11:50 AM, Roger Riggs wrote:
Hi Alexander,
Ok, thanks
Note: code reviews of code going into the sandbox is not a substitute
for code review when it is to be pushed to jdk/jdk.
(The sandbox has much more informal rules for commits that are branch
specific.)
sure - we will do a
Hi Deepak,
I see the following comment is not addressed yet:
> - Line 163,198: Exception messages are incorrect. they are for
isJavaIdentifierStart().
Naoto
On 2/20/19 8:53 AM, Deepak Kejriwal wrote:
Thanks Naoto San and Sean for review. I have incorporate all the comments.
Please find
Hi Alexander,
Ok, thanks
Note: code reviews of code going into the sandbox is not a substitute
for code review when it is to be pushed to jdk/jdk.
(The sandbox has much more informal rules for commits that are branch
specific.)
Roger
On 02/19/2019 10:44 PM, Alexander Matveev wrote:
Hi
Thanks Naoto San and Sean for review. I have incorporate all the comments.
Please find below updated version of webrev :-
http://cr.openjdk.java.net/~rpatil/JapaneseEra_and_Currency_changes_8u/webrev.01/
Regards,
Deepak
-Original Message-
From: Naoto Sato
Sent: Tuesday, February 19,
Hi Goetz,
Forgive me for jumping in here and, possibly, misunderstanding what you
want -- I may have misunderstood what you are trying to do as I have not
been following this thread carefully.
On 20/02/2019 16:36, Lindenmaier, Goetz wrote:
> 1. As I understand, it would be simple to extend ASM
Hi Remi,
> yes, it's a feature of ASM, offer the right abstraction to do bytecode
> generation/transformation i.e. a stream of opcodes that are more abstract
> than the real bytecode, so there is no way to get a direct access to the
> bytecode at a specific BCI.
For the generation of the NPE
Hi Deepak,
The same comment for 11u can be applied here too:
> - Line 163,198: Exception messages are incorrect. they are for
isJavaIdentifierStart().
Naoto
On 2/20/19 8:57 AM, Deepak Kejriwal wrote:
Thanks Naoto San and Sean for review. I have incorporate all the comments.
Please find
On 20/02/2019 18:27, Mandy Chung wrote:
Here is the new webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.01/
Looks good.
Thanks Mandy!
I suggest to make the javadoc clear that isLoggable accepts null
@param record a {@code LogRecord} or {@code null}
Right - here is an
On 2/20/19 10:57 AM, Daniel Fuchs wrote:
Right - here is an updated webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.02/
Looks good.
Mandy
Hi Daniel,
I return today from vacation.
On 2/15/19 10:46 AM, Daniel Fuchs wrote:
Hi Mandy,
Here is the new webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8216363/webrev.01/
Looks good.
I suggest to make the javadoc clear that isLoggable accepts null
@param record a {@code
its on my todo list as is looking at your other issue, just have not gotten to
it yet :-)
> On Feb 20, 2019, at 1:44 PM, Philipp Kunz wrote:
>
> Hi Jon,
>
> All right, let's not document flushing behavior then. It's probably really
> not important enough. So we're back to the null-checks?
>
Hi Jon,
All right, let's not document flushing behavior then. It's probably
really not important enough. So we're back to the null-checks?For that
see patch of https://mail.openjdk.java.net/pipermail/core-libs-dev/2019
-February/058576.html
Regards,Philipp
On Sat, 2019-02-16 at 17:05 -0800,
I was actually missing at least one of the map methods. I have a method
that is returning an OptionalInt, and I wanted to easily turn that into
an Optional by applying mapToObj(Integer::valueOf). The same
could also be done for OptionalLong -> Optional and OptionalDouble
-> Optional.
Thanks, Nishit.
I'd still like to ask for a review from a Reviewer.
Naoto
On 2/20/19 12:33 AM, Nishit Jain wrote:
Hi Naoto,
Thanks for the explanation. Change looks fine to me.
Regards,
Nishit Jain
On 19-02-2019 22:51, Naoto Sato wrote:
Hi Nishit,
The reason is that "US" is the only
Please review the simple patch to fix [1] at [2]. The patch is simply
adding a comment to the API, (javadoc) to sync it with the implementation.
Thanks,
Vicente
[1] https://bugs.openjdk.java.net/browse/JDK-8219480
[2] http://cr.openjdk.java.net/~vromero/8219480/webrev.00/
Hi Naoto,
Thanks for the explanation. Change looks fine to me.
Regards,
Nishit Jain
On 19-02-2019 22:51, Naoto Sato wrote:
Hi Nishit,
The reason is that "US" is the only required locale in the JDK (cf.
Locale.getAvailableLocales(). In fact, initially I supplied "001" with
it, as it means
On 19/02/2019 18:01, Andrew Dinn wrote:
:
My reason for using capacity() was that I was swayed by the original
implementation of force(). It calls
force0(fd, mappingAddress(offset), mappingLength(offset))
:
I'm wondering if this ought to remain as is or ought to change to
specify limit()?
On 20/02/2019 11:11, Alan Bateman wrote:
> On 19/02/2019 18:01, Andrew Dinn wrote:
>> :
>> My reason for using capacity() was that I was swayed by the original
>> implementation of force(). It calls
>>
>> force0(fd, mappingAddress(offset), mappingLength(offset))
>>
>> :
>>
>> I'm wondering if
24 matches
Mail list logo
