I can sponsor this for you.
.. Thomas
On Thu, Feb 6, 2020, 04:35 Patrick Zhang OS
wrote:
> Does this require one more “yes” from any other reviewer?
>
>
>
> And may I ask for any committer’s help to sponsor and push it (once
> approved)? Thanks in advance.
>
>
>
> Regards
>
> Patrick
>
>
>
>
Does this require one more “yes” from any other reviewer?
And may I ask for any committer’s help to sponsor and push it (once approved)?
Thanks in advance.
Regards
Patrick
From: Thomas Stüfe
Sent: Wednesday, February 5, 2020 11:16 PM
To: Patrick Zhang OS
Cc: core-libs-dev
Subject: Re: RFR:
Hello!
j.u.regex.Pattern supports a special char class \R, which is specified
to be equal to \u000D\u000A|[\u000A\u000B\u000C\u000D\u0085\u2028\u2029].
In particular, this means that the input "\r\n" must match to both
patterns \R and \R\R.
(In the later case, first \R matches \r and
Hi Leonid,
Thanks for the comment, I have updated the CSR [1]
Vicente
[1] https://bugs.openjdk.java.net/browse/JDK-8238240
On 2/5/20 7:55 PM, Leonid Kuskov wrote:
Although methods (toString, hashCode) return different
representations of a record (either textual or algorithmic)
Spec for
Hi Leonid,
Thanks for the comment, I have updated the CSR [1]
Vicente
[1] https://bugs.openjdk.java.net/browse/JDK-8238240
On 2/5/20 7:55 PM, Leonid Kuskov wrote:
Although methods (toString, hashCode) return different
representations of a record (either textual or algorithmic)
Spec for
Although methods (toString, hashCode) return different representations
of a record (either textual or algorithmic)
Spec for String toString(); everywhere refers to "the object":
* Returns a string representation of the object.
* @return a string representation of the object.
from the other
OK - this makes sense - will update tomorrow.
/Andy
On 2/5/2020 4:24 PM, Alexander Matveev wrote:
Hi Andy,
Fix looks good, but I think we should do same for --resource-dir. I do
not think that non-existing directory should be same as empty. User
might misspell directory name and it will not
+1
Paul.
> On Feb 5, 2020, at 2:36 PM, Vicente Romero wrote:
>
> forwarding to compiler dev, I need a reviewer for this change,
>
> Thanks,
> Vicente
>
>
> Forwarded Message
> Subject: RFR: JDK-8238239: java.lang.Record spec clarifications
> Date: Tue, 4 Feb 2020
forwarding to compiler dev, I need a reviewer for this change,
Thanks,
Vicente
Forwarded Message
Subject:RFR: JDK-8238239: java.lang.Record spec clarifications
Date: Tue, 4 Feb 2020 15:38:02 -0500
From: Vicente Romero
To: core-libs-dev
Please review the
Stuart, Martin, Kiran,
I think this "bug" should not be fixed because it's one of the cases where
providing more information is actually bad from a user POV.
The current code throws NoSuchElementException when the iterator reach the end
so from the user POV, this is the right exception because
Hi Andy,
Fix looks good, but I think we should do same for --resource-dir. I do
not think that non-existing directory should be same as empty. User
might misspell directory name and it will not be clear for user why we
not using information from --resource-dir.
Thanks,
Alexander
On
- Mail original -
> De: "Сергей Цыпанов"
> À: "Remi Forax" , "core-libs-dev"
>
> Envoyé: Mercredi 5 Février 2020 22:12:34
> Objet: Re: [PATCH] Enhancement proposal for java.util.StringJoiner
> Hello,
>
>> If you want to optimize StringJoiner, the best way to do it is to use the
>>
Hello,
> If you want to optimize StringJoiner, the best way to do it is to use the
> shared secret mechanism so a java.util class can see implementation details
> of a java.lang class without exposing those details publicly.
> As an example, take a look to EnumSet and its implementations.
I've
Thanks Stuart and Martin,
Here is an updated webrev with the changes.
http://cr.openjdk.java.net/~kravikumar/8161558/webrev.01/
JBS: https://bugs.openjdk.java.net/browse/JDK-8161558
Thanks,
Kiran
On 15/01/2020 12:46, Martin Buchholz wrote:
Hi Kiran,
Looks good to me, but I always
This simple fix [1] to jpackage bug [2] simply adds a proper error
message when --runtime-image points to a non-existent directory path.
[1] http://cr.openjdk.java.net/~herrick/8237967/webrev.01/index.html
[2] https://bugs.openjdk.java.net/browse/JDK-8237967
/Andy
On 05/02/2020 15:31, Peter Levart wrote:
I think this is about allow the InitialContextFactory instance to be
GC'ed when the thread is long lived. It might not be a concern for the
LDAP or the other providers in the JDK.
-Alan
Ah, I see. You mean when the ClassLoader is long lived. So this
Hi All,
Any opinion on this?
Is it the right forum to ask for opinion? if it is not, could you guys
guide me to right forum?
Thanks
Rajiv
On Mon, Feb 3, 2020 at 5:27 PM Rajiv wrote:
> Hi All
>
> I want to introduce a new declarative syntax for conditional statements in
> java on the line of
Hi Erik,
> Hello,
>
> New webrev: http://cr.openjdk.java.net/~erikj/8238225/webrev.02/
>
> On 2020-02-05 02:17, Langer, Christoph wrote:
> > Hi,
> >
> > we've tested the patch and all reported failure scenarios we're aware of
> are fixed with that, so basically, ship it
> >
> > As for the
Looks good to me as well!
I'll sponsor this and push it.
Best regards,
Volker
On Wed, Feb 5, 2020 at 6:47 AM Roger Riggs wrote:
>
> Looks good, Thanks
>
> On 2/4/20 8:06 PM, Verghese, Clive wrote:
> > Thank you for the quick feedback.
> >
> > I have updated the Webrev
> >
Hello,
New webrev: http://cr.openjdk.java.net/~erikj/8238225/webrev.02/
On 2020-02-05 02:17, Langer, Christoph wrote:
Hi,
we've tested the patch and all reported failure scenarios we're aware of are
fixed with that, so basically, ship it
As for the code review part:
The patch I've tested
On 2/5/20 2:46 PM, Alan Bateman wrote:
On 05/02/2020 11:53, Peter Levart wrote:
:
Please, include me in the conversation. I would like to know whether
this is really possible, because I think it is not. If the
implementation class / provider type is resolved using thread's
context class
All still good.
...Thomas
On Wed, Feb 5, 2020 at 3:42 PM Patrick Zhang OS <
patr...@os.amperecomputing.com> wrote:
> Thanks for your comments, Thomas.
>
>
>
> I have no accurate knowledge regarding why parentPathv was initially
> written as a global var instead of a member in ChildStuff struct
Looks good, Thanks
On 2/4/20 8:06 PM, Verghese, Clive wrote:
Thank you for the quick feedback.
I have updated the Webrev
http://cr.openjdk.java.net/~alvdavi/webrevs/8235699/webrev.8u.jdk.06/
Regards,
Clive Verghese
On 2/4/20, 4:42 PM, "core-libs-dev on behalf of Roger Riggs"
wrote:
Thanks for your comments, Thomas.
I have no accurate knowledge regarding why parentPathv was initially written as
a global var instead of a member in ChildStuff struct initialized in
jspawnhelper.c. However the suggested change might not be very straight-forward
as there are other references
On 05/02/2020 11:53, Peter Levart wrote:
:
Please, include me in the conversation. I would like to know whether
this is really possible, because I think it is not. If the
implementation class / provider type is resolved using thread's
context class loader, then it is the responsibility of
On 2/5/20 12:53 PM, Peter Levart wrote:
On 2/5/20 9:31 AM, Seán Coffey wrote:
Thanks again for the review Peter. There's an off-thread conversation
around whether the ClassLoaderValue should hold SoftReferences to the
Factory that's stored with the classloader. I think we're looking at
On 2/5/20 9:31 AM, Seán Coffey wrote:
Thanks again for the review Peter. There's an off-thread conversation
around whether the ClassLoaderValue should hold SoftReferences to the
Factory that's stored with the classloader. I think we're looking at a
possible leak otherwise.
i.e.
Hi,
we've tested the patch and all reported failure scenarios we're aware of are
fixed with that, so basically, ship it
As for the code review part:
The patch I've tested had removed the "-1" in line 532, so that seems to be
correct. As Magnus wrote, the pattern seems to be copied from the
On 2020-02-04 18:45, Erik Joelsson wrote:
Does anyone have an opinion on this?
The solution seems sound to me. I'm having a hard time figuring out if
the string manipulations in java_md_macosx.m are correct; as Christoph
is saying, they might not be. I realize you have copied an existing
Hi Erik,
> Does anyone have an opinion on this?
Yep, first of all, thanks for doing this work. Sorry for not replying earlier
but FOSDEM/openjdkcw has kept us a bit busy. We're in the process of testing
your change in the reported cases where behavior is broken and shall supply you
with
Thanks again for the review Peter. There's an off-thread conversation
around whether the ClassLoaderValue should hold SoftReferences to the
Factory that's stored with the classloader. I think we're looking at a
possible leak otherwise.
i.e. ClassLoaderValue>
I'm looking into that now.
Also -
31 matches
Mail list logo
