Please review some fixes to address issues found by doclint.
In a couple of places, imports were required in order to resolve symbols.
In another case, the name also had a typo in it.
In the last case, the incorrect syntax was used for a type parameter in
@param.
-- Jon
JBS: https://bugs.open
http://cr.openjdk.java.net/~almatvee/8225251/webrev.01/
- Expended "import static org.junit.Assert.*" and "import static
jdk.incubator.jpackage.internal.StandardBundlerParam.*".
- Fixed inconsistency between imported StandardBundlerParam or when used
directly. See
http://cr.openjdk.java.net/~a
Hi Martin,
Any update on this? Thanks!
Best,
John Lin
林自均 於 2020年6月13日 週六 上午11:08寫道：
>
> Hi Martin,
>
> I see your point. Thank you for demostrating this for me.
>
> Here's my updated patch:
>
> # HG changeset patch
> # User John Lin
> # Date 1591923561 -28800
> # Fri Jun 12 08:59:21 2020
I'm fine with it either way - the main thing is what you have done.
/Andy
On 6/19/2020 6:02 PM, alexander.matv...@oracle.com wrote:
Hi Alexey,
Andy mentioned in issue description not to expend static imports, this
is why all static imports were not expended. I can expend them or we
can keep
Hi Alexey,
Andy mentioned in issue description not to expend static imports, this
is why all static imports were not expended. I can expend them or we can
keep as is. I am fine with either way. Andy any comments why we do not
need to expend static imports?
Thanks,
Alexander
On 6/19/20 10:49
Looks good!
Thanks
Maurizio
On 19/06/2020 11:56, Chris Hegarty wrote:
Paul, Maurizio,
This version incorporates all feedback so far.
https://cr.openjdk.java.net/~chegar/8247696/webrev.01/
Results on my machine:
Benchmark Mode Cnt Score Error Units
BulkOps.mismatch_large_byteb
This is how they were ut in unit tests initially. I'm OK either way,
just wanted to double check these imports were not overlooked.
- Alexey
On 6/19/2020 12:30 PM, Kevin Rushforth wrote:
That a reasonably common pattern in JUnit tests, but expanding them to
individual static imports is, of cou
That a reasonably common pattern in JUnit tests, but expanding them to
individual static imports is, of course, fine as well.
-- Kevin
On 6/19/2020 9:08 AM, Alexey Semenyuk wrote:
Alexander,
There is still
---
import static org.junit.Assert.*;
---
in unit tests. Is this intended?
- Alexey
Alexander,
There is still
---
import static org.junit.Assert.*;
---
in unit tests. Is this intended?
- Alexey
On 6/19/2020 4:46 AM, alexander.matv...@oracle.com wrote:
Please review the jpackage fix for bug [1] at [2].
Cleanup import statements.
[1] https://bugs.openjdk.java.net/browse/JDK-8
Hi Peter,
User-defined is a bit ambiguous but includes the appClassLoader since
its contents
are controlled by classpath and module path properties and command line
arguments.
Thanks, Roger
On 6/18/20 2:24 PM, Peter Kessler (Open Source) wrote:
Roger,
You are right that the existing code
Hi, Sergey,
On 6/19/20 11:33 AM, Сергей Цыпанов wrote:
Hello Remi,
thanks for pointing this out, I didn't take this into account.
As I understand, the volatile semantics here covers all the fields of an object,
no matter whether they are declared before or after volatile field (probably
actua
On 19/06/2020 11:25 pm, David Holmes wrote:
Hi Remi,
On 19/06/2020 6:03 pm, Remi Forax wrote:
Hi Sergei,
the problem is that you are changing the semantics if there are
several fields.
By example with the code below, you have the guarantee that the code
will print 4 (if it prints something)
Hi Remi,
On 19/06/2020 6:03 pm, Remi Forax wrote:
Hi Sergei,
the problem is that you are changing the semantics if there are several fields.
By example with the code below, you have the guarantee that the code will print
4 (if it prints something),
if you remove the assignment field = false, t
Hi Remi,
On 6/19/20 10:03 AM, Remi Forax wrote:
Hi Sergei,
the problem is that you are changing the semantics if there are several fields.
By example with the code below, you have the guarantee that the code will print
4 (if it prints something),
if you remove the assignment field = false, the
all looks good.
/Andy
On 6/19/2020 4:46 AM, alexander.matv...@oracle.com wrote:
Please review the jpackage fix for bug [1] at [2].
Cleanup import statements.
[1] https://bugs.openjdk.java.net/browse/JDK-8225251
[2] http://cr.openjdk.java.net/~almatvee/8225251/webrev.00/
Thanks,
Alexander
Paul, Maurizio,
This version incorporates all feedback so far.
https://cr.openjdk.java.net/~chegar/8247696/webrev.01/
Results on my machine:
Benchmark Mode Cnt ScoreError Units
BulkOps.mismatch_large_bytebuffer avgt 30 88266.728 ? 4083.476 ns/op
B
Hi Daniel,
Thank you for the feedback.
I have added the new case for thread id > Integer.MAX_VALUE.
have updated comments/names and string to JDK 16.
I will follow-up with a new JBS issue for the backport
webrev :
http://cr.openjdk.java.net/~ryadav/webrev_8245302/webrev.00/index.html
- rahul
Hello Remi,
thanks for pointing this out, I didn't take this into account.
As I understand, the volatile semantics here covers all the fields of an
object,
no matter whether they are declared before or after volatile field (probably
actual object layout might be different from declaration in so
Thank you Alan, updated webrev.
webrev :
http://cr.openjdk.java.net/~ryadav/webrev_8245302/webrev.00/index.html
- rahul
On 19/06/2020 08:43, Alan Bateman wrote:
On 18/06/2020 23:37, Rahul Yadav wrote:
Hi Alan,
Thank you for the feedback.I have updated the webrev.
webrev :
http://cr.openj
Hi Rahul,
This looks very good.
I have some comments regarding the SerializeLogRecord test:
- the test speaks of JDK 15 at several places: is it really JDK 15, or
should it be JDK 16? I mean - was the serialized bytes generated
before your fix or after?
- the generate() method (no args) sh
Please review the jpackage fix for bug [1] at [2].
Cleanup import statements.
[1] https://bugs.openjdk.java.net/browse/JDK-8225251
[2] http://cr.openjdk.java.net/~almatvee/8225251/webrev.00/
Thanks,
Alexander
Hi Sergei,
the problem is that you are changing the semantics if there are several fields.
By example with the code below, you have the guarantee that the code will print
4 (if it prints something),
if you remove the assignment field = false, the code can print 0 or 4.
class A {
int i = 4;
On 19/06/2020 05:57, Сергей Цыпанов wrote:
Hello,
while investigating an issue I've found out that assignment of default value to
volatile fields slows down object instantiation.
Yes, there's been several efforts over the years to eliminate the
initializing volatile fields to their default
On 18/06/2020 23:37, Rahul Yadav wrote:
Hi Alan,
Thank you for the feedback.I have updated the webrev.
webrev :
http://cr.openjdk.java.net/~ryadav/webrev_8245302/webrev.00/index.html
This looks quite good.
The comment in shortShortID has "any positive long less than
Integer.MAX_VALUE" but i
Looks good and trivial!
Thanks,
David
On 19/06/2020 10:18 am, Jonathan Gibbons wrote:
Please review this trivial fix to some minor issues reported by doclint.
In the first change, the `` contained a hangover of some HTML 4
attributes
which are not supported in HTML5. They are simply deleted
25 matches
Mail list logo
