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 a
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 PM,
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/
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 requir
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.
However,
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
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
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?
> F
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, Jonath
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 LogRecord}
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 bel
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 bel
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 to
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 f
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, 20
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
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 Roge
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 messa
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
> descr
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 buff
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())
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 th
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()?
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 the
24 matches
Mail list logo
