You have enough reviews now, but thanks for fixing this.
..Thomas
On Thu, Apr 30, 2020 at 4:15 PM Baesken, Matthias
wrote:
> Hello, please look into this small fix for a link error we faced on
> Windows 32bit.
>
> Currently we run into this link error :
> jpackageapplauncher
>
> * For target
>
Hi Jay,
OK, welcome! I'll sponsor this changeset for you. It's pretty simple, so I'll
just paste the exported changeset below. (For complicated changesets, you'll
have to ask a sponsor to host a webrev on cr.openjdk.java.net for you.) Please
check the Contributed-by line in the changeset to ma
Hi Andy,
Looks good.
Thanks,
Alexander
On 4/30/20 4:18 PM, Andy Herrick wrote:
revised webrev at [3] - copyrights were updated by previous issue.
/Andy
[3] http://cr.openjdk.java.net/~herrick/8244018/webrev.02/
On 4/29/2020 4:56 PM, Alexander Matveev wrote:
Hi Andy,
http://cr.openjdk.java.
revised webrev at [3] - copyrights were updated by previous issue.
/Andy
[3] http://cr.openjdk.java.net/~herrick/8244018/webrev.02/
On 4/29/2020 4:56 PM, Alexander Matveev wrote:
Hi Andy,
http://cr.openjdk.java.net/~herrick/8244018/webrev.01/src/jdk.incubator.jpackage/share/classes/jdk/incubat
The general rule in the collections that wrappers and views don't divulge their
backing collections. The reason is fairly obvious for things like the checked
wrappers and unmodifiable wrappers, but it's equally important for various view
collections like those of Lists, Sets, and Maps. If there
Looks good.
- Alexey
On 4/30/2020 11:23 AM, Andy Herrick wrote:
Modified due to failure of new test on macosx. The relative location
of "release" file is different.
Please review revised fix [7]
/Andy
[7] - http://cr.openjdk.java.net/~herrick/8219536/webrev.06/
On 4/29/2020 5:01 PM, Alexe
OK, great, I've closed out the bug.
s'marks
On 4/29/20 10:29 PM, Jayashree Sk1 wrote:
Stuart, Thanks for all the details.
All you have said makes sense to me, I have no contention for closing this
issue as Won't Fix (am not related to originator, picked this issue up as
starters to understan
Hi Andy,
Looks good.
Thanks,
Alexander
On 4/30/20 8:23 AM, Andy Herrick wrote:
Modified due to failure of new test on macosx. The relative location
of "release" file is different.
Please review revised fix [7]
/Andy
[7] - http://cr.openjdk.java.net/~herrick/8219536/webrev.06/
On 4/29/202
+1
Best regards,
Martin
From: Alexey Semenyuk
Sent: Donnerstag, 30. April 2020 18:29
To: Baesken, Matthias ; core-libs-dev
Cc: Doerr, Martin
Subject: Re: RFR [XXS] : 8244183: linker error jpackageapplauncher on Windows
32bit
Looks good assuming the patch was tested with 64bit build.
- Ale
If the float (binary32) case is of any guidance about the soundness of
the algorithm and the validity of the implementation, *all* of the 2^32
float bit patterns pass the extensive tests of the contribution in less
than a couple of hours, as mentioned in past posts.
As a peace of mind, even
Hi Remi,
Thanks for the feedback. We can take this off from this review thread
and roll it into JDK-8230501.
Mandy
On 4/30/20 11:03 AM, fo...@univ-mlv.fr wrote:
Hi Mandy,
i've taken a look to the code,
i think it's better to have two methods, one for List and one for Map
to avoid to have a
On 30/04/2020 01:06, Peter Levart wrote:
Think differently: what if the client succeeded in closing the
segment, just because it did it in a time window when no thread in the
thread pool held an open scope (this is entirely possible with
parallel stream for example since threads periodically
Hi Mandy,
i've taken a look to the code,
i think it's better to have two methods, one for List and one for Map to avoid
to have a bootstrap argument ( classDataType ) and to have a code more
straightforward.
Rémi
> De: "mandy chung"
> À: "Remi Forax" , "Jorn Vernee"
> Cc: "Maurizio Cimada
Thanks Chris,
I'll make sure this is included in the next iteration!
Cheers
Maurizio
On 30/04/2020 16:07, Chris Hegarty wrote:
Maurizio,
On 30 Apr 2020, at 15:35, Maurizio Cimadamore
wrote:
Looks good - thanks. Perhaps I'd tweak "will hold" and replace it with "will feature",
and also add
On 2020-04-30 15:29, Alan Bateman wrote:
On 30/04/2020 13:54, Raffaello Giulietti wrote:
Hi,
after more than one year after first publication, the patches [1] and
the CSR [2] are still awaiting a review...
Here's a breakdown of estimated times:
* Reading the CSR: 15-30 min. This can be done
Looks good assuming the patch was tested with 64bit build.
- Alexey
On 4/30/2020 10:12 AM, Baesken, Matthias wrote:
Hello, please look into this small fix for a link error we faced on
Windows 32bit.
Currently we run into this link error :
jpackageapplauncher
* For target
support_native_jd
Hi Fernando,
Thanks for the update. Here's the updated webrev. The previous webrev
was moved to webrev01.
http://cr.openjdk.java.net/~joehw/jdk15/8183266/webrev02/
This change looks good to me.
Best,
Joe
On 4/29/2020 9:38 AM, Joe Wang wrote:
Hi Fernando,
Thanks for adding coverage to this
Looks good, and trivial.
Thanks,
Paul
On 4/30/20, 8:23 AM, "core-libs-dev on behalf of Volker Simonis"
wrote:
Hi,
can I please get a review for the following trivial change which fixes
the Amazon copyright in several test files:
http://cr.openjdk.java.net/~simonis/webrevs/20
Modified due to failure of new test on macosx. The relative location of
"release" file is different.
Please review revised fix [7]
/Andy
[7] - http://cr.openjdk.java.net/~herrick/8219536/webrev.06/
On 4/29/2020 5:01 PM, Alexey Semenyuk wrote:
Looks good.
- Alexey
On 4/29/2020 2:36 PM, And
Hi,
can I please get a review for the following trivial change which fixes
the Amazon copyright in several test files:
http://cr.openjdk.java.net/~simonis/webrevs/2020/8244094/
https://bugs.openjdk.java.net/browse/JDK-8244094
Notice that the new version intentionally contains no copyright year a
Maurizio,
> On 30 Apr 2020, at 15:35, Maurizio Cimadamore
> wrote:
>
> Looks good - thanks. Perhaps I'd tweak "will hold" and replace it with "will
> feature", and also add a link between "access modes" to the access mode
> section of the javadoc, to make it more navigable.
Done.
https://c
Looks good - thanks. Perhaps I'd tweak "will hold" and replace it with
"will feature", and also add a link between "access modes" to the access
mode section of the javadoc, to make it more navigable.
Maurizio
On 30/04/2020 14:33, Chris Hegarty wrote:
Maurizio,
On 23 Apr 2020, at 21:33, Mau
Hello, please look into this small fix for a link error we faced on Windows
32bit.
Currently we run into this link error :
jpackageapplauncher
* For target
support_native_jdk.incubator.jpackage_jpackageapplauncher_BUILD_JPACKAGE_APPLAUNCHEREXE_link:
LINK : fatal error LNK1561: entry point must
Maurizio,
> On 23 Apr 2020, at 21:33, Maurizio Cimadamore
> wrote:
>
>
> Javadoc:
>
> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/javadoc
>
I’m still working my way through this update ( BTW it’s looking very good ),
but an initial comment on the API.
The access modes of MemorySegm
On 30/04/2020 13:54, Raffaello Giulietti wrote:
Hi,
after more than one year after first publication, the patches [1] and
the CSR [2] are still awaiting a review...
Here's a breakdown of estimated times:
* Reading the CSR: 15-30 min. This can be done and approved
independently.
* Checking t
Hi,
after more than one year after first publication, the patches [1] and
the CSR [2] are still awaiting a review...
Here's a breakdown of estimated times:
* Reading the CSR: 15-30 min. This can be done and approved independently.
* Checking that the implementation matches the documentation [
Hi Stuart,
In general I agree with you regarding synchronized collections. But
nevertheless there is a lot of legacy code that still uses synchronized
wrappers. And sometimes synchronization is done on wrong lock object, which
leads to relatively rare but extremely hard to reproduce and troublesho
27 matches
Mail list logo
