+1
Best,
Joe
On 4/7/20 12:48 PM, naoto.s...@oracle.com wrote:
Thanks Roger. I will fix the typo before the push.
Naoto
On 4/7/20 12:47 PM, Roger Riggs wrote:
Hi Naoto,
Looks fine.
In EquivMapsGenerator.java.
typo:
grandfahered -> grandfathered Thanks, Roger
On 4/7/20 1:52 PM,
[Note review on both core-libs and hotspot-gc-dev lists; try not to lose
either when replying.]
Please review a new function: java.lang.ref.Reference.refersTo.
This function is needed to test the referent of a Reference object
without artificially extending the lifetime of the referent object,
On 2020-04-03 15:36, Langer, Christoph wrote:
Eventually I came up with this result and then I also asked myself the question
whether the new complexity was worth the benefit. I answered myself with a yes
(though definitely not a clear one ), and that's why I proposed the change.
After
Hi Andy,
Yes, it is fine to fix test in followup CR.
Thanks,
Alexander
On 4/7/20 5:11 AM, Andy Herrick wrote:
Alexander:
Can I take it your OK with revising these tests in the followup CR ?
/Andy
On 4/4/20 8:53 AM, Andy Herrick wrote:
I think it best to modify these checks as part of a
2020/4/3 6:36:53 -0700, christoph.lan...@sap.com:
> 2020/4/2 14:12:54 -0700, mark.reinh...@oracle.com:
>> I thought about doing this when I originally wrote that plugin, but it’s
>> so awkward to achieve with ASM -- as demonstrated by your patch -- that
>> I concluded it wasn’t worth it. Who will
Looks good to me, thanks!
Kind regards,
Ivan
On 4/7/20 8:28 AM, Pavel Rappo wrote:
Hi Ivan,
On 7 Apr 2020, at 09:11, Ivan Gerasimov wrote:
Hi Pavel!
A couple of comments.
1)
java/util/logging/Formatter.java
This has one extra open curly brace:
"{{@literal }"
The leftmost curly brace
Hi Pavel,
On 4/7/2020 1:07 PM, Pavel Rappo wrote:
Thanks, Joe. I presume you mean me changing this
* {@code interface}
to this
* {@code @interface}
Correct.
Right? If so, then it renders the same way, and the `@interface` does not
confuse the Standard Doclet. After
Thanks, Joe. I presume you mean me changing this
* {@code interface}
to this
* {@code @interface}
Right? If so, then it renders the same way, and the `@interface` does not
confuse the Standard Doclet. After JDK-8241780 "Allow \n@ inside inline tags"
has been done and dusted we'll never
Thanks Roger. I will fix the typo before the push.
Naoto
On 4/7/20 12:47 PM, Roger Riggs wrote:
Hi Naoto,
Looks fine.
In EquivMapsGenerator.java.
typo:
grandfahered -> grandfathered Thanks, Roger
On 4/7/20 1:52 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the
Hi Naoto,
Looks fine.
In EquivMapsGenerator.java.
typo:
grandfahered -> grandfathered Thanks, Roger
On 4/7/20 1:52 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8242010
The proposed changeset is located at:
Hi Pavel,
Looks fine in general, assuming the change to Class.java renders
correctly in output.
Thanks,
-Joe
On 4/7/2020 8:28 AM, Pavel Rappo wrote:
Hi Ivan,
On 7 Apr 2020, at 09:11, Ivan Gerasimov wrote:
Hi Pavel!
A couple of comments.
1)
java/util/logging/Formatter.java
This has
I created this webrev to also fix the second part that was previously fixed
as part of 8202469:
http://cr.openjdk.java.net/~winterhalter/8202473/webrev.00/ - this would be
the second part of the adjustment.
This is reported in https://bugs.openjdk.java.net/browse/JDK-8202473 and
was closed as a
Hi Pavel,
> On Apr 7, 2020, at 11:11 PM, Pavel Rappo wrote:
>
> I assume you have signed the OCA [1]. If not and you want to continue, please
> do it. If you've already done so, which is probably the case [2], please
> attach your patch as text to this thread with the next email. Do not use
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8242010
The proposed changeset is located at:
https://cr.openjdk.java.net/~naoto/8242010/webrev.00/
Besides the upgrade of the data file, I fixed the issue where
EquivMapsGenerator had been
I assume you have signed the OCA [1]. If not and you want to continue, please
do it. If you've already done so, which is probably the case [2], please attach
your patch as text to this thread with the next email. Do not use zip or the
like. I will take it from there and sponsor that for you.
The langtools test changes look OK. I investigated TestRecordTypes.java
a bit because of the "jdk11" component in the file name, but the changes
look OK, and there is caveat text in the test itself to indicate the
file should be updated at some point to a more recent version anyway.
-- Jon
Hi Ivan,
On 07/04/2020 09:11, Ivan Gerasimov wrote:
1)
java/util/logging/Formatter.java
This has one extra open curly brace:
"{{@literal }"
That one looks like a typo but is not a typo.
It means: if the string contains "{0" or "{1" or ...
cheers,
-- daniel
Hi Ivan,
> On 7 Apr 2020, at 09:11, Ivan Gerasimov wrote:
>
> Hi Pavel!
>
> A couple of comments.
>
> 1)
> java/util/logging/Formatter.java
>
> This has one extra open curly brace:
>
> "{{@literal }"
The leftmost curly brace is not a part of the "literal" inline tag, but rather
a part of
Hi David,
> why did you introduce a new block scope?
To separate the action block from the other code. "A Poor/lazy man's
method". I've preferred to lay it out this way because it makes the code
more compact and easy to read (as opposing to looking for a only-once
used method in some other
Hi Evgeny,
On 7/04/2020 6:33 pm, Evgeny Nikitin wrote:
Hi David,
I'm not at all sure this is generally what we want for every single
test that uses ProcessTools! But I'm willing it to see it trialed.
Well, it's mostly used for test VM runs. In runs I performed (artificial
"failures"
Alexander:
Can I take it your OK with revising these tests in the followup CR ?
/Andy
On 4/4/20 8:53 AM, Andy Herrick wrote:
I think it best to modify these checks as part of a separate issue,
and leave these checks disabled as part of JDK-8237490. I have filed
JDK-8242155 to enhance these
On 06/04/2020 18:36, Henry Jen wrote:
Here is the combined webrev[1] which I think is what we should have. By using
__solaris__, we make sure no extra define from build and assuming that all
solaris build will have gethrtime() and use that.
The current build only use that for static build
Hi David,
I'm not at all sure this is generally what we want for every single
test that uses ProcessTools! But I'm willing it to see it trialed.
Well, it's mostly used for test VM runs. In runs I performed (artificial
"failures" included) the amounts of output were very small.
Please run
Hi Pavel!
A couple of comments.
1)
java/util/logging/Formatter.java
This has one extra open curly brace:
"{{@literal }"
2)
grep finds some more typos of the same kind that you've spotted.
a) rgrep '^[ ]*\*'|grep ' ,'|less
This find number of potential typos. For example, the javadoc for
24 matches
Mail list logo
