Hi Harold,
Adding serviceability-dev for the serviceability related changes.
Nit: "VM support for sealed classes"
This RFR covers the VM, core-libs, serviceability and even some
langtools tests. AFAICS only the javac changes are not included here so
when and where will they be reviewed and un
You might want to check the /generated/ API docs. It doesn't look like
the first {@link} will do what you might be expecting.
-- Jon
On 5/18/20 1:48 PM, Claes Redestad wrote:
Hi,
let's add an isEmpty default method to CharSequence!
Webrev: http://cr.openjdk.java.net/~redestad/8215401/open.00
Hi,
Please review this patch for the compiler, javadoc and javax.lang.model
support for the JEP 360 Sealed Classes (Preview). The changes are
provided at [1], which implements the latest JLS for sealed types [2].
The patch also include the needed changes to javadoc and
javax.lang.model to sup
Hi Claes,
Though it does not look like it could be any simpler, there should
probably be a test.
Checking consistency with the existing implementations of
CharSequence.length()
and a custom subtype.
Thanks, Roger
On 5/18/20 4:48 PM, Claes Redestad wrote:
Hi,
let's add an isEmpty default m
looks good Joe
> On May 18, 2020, at 6:04 PM, Joe Wang wrote:
>
> As it appears, I was missing a comma in the header as well (see
> https://bugs.openjdk.java.net/browse/JDK-8245238)
>
> The webrev is updated with the comma added (to PredicatedNodeTest.java)
> http://cr.openjdk.java.net/~joehw/
As it appears, I was missing a comma in the header as well (see
https://bugs.openjdk.java.net/browse/JDK-8245238)
The webrev is updated with the comma added (to PredicatedNodeTest.java)
http://cr.openjdk.java.net/~joehw/jdk15/8245231/webrev/
Thanks,
Joe
On 5/18/2020 1:53 PM, Joe Wang wrote:
T
Hi Brent,
Thank you very much indeed for your serious answer.
Still a lot of work left but to start with I randomly picked Ant and
found it suffers a bug. See attached bunch of files to reproduce.
The bug does not occur with my proposed patch. One reason for this bug
to occur is cutting and concate
Thanks Mark.
-Joe
On 5/18/2020 1:49 PM, mark sheppard wrote:
Hi Joe,
all good I think. 👍
regards
Mark
*From:* Joe Wang
*Sent:* Monday 18 May 2020 19:36
*To:* mark sheppard ;
core-libs-dev@openjdk.java.net
*Cc:* Mark
Hi Joe,
all good I think. 👍
regards
Mark
From: Joe Wang
Sent: Monday 18 May 2020 19:36
To: mark sheppard ; core-libs-dev@openjdk.java.net
Cc: Mark Sheppard
Subject: Re: RFR [15] 8244342: Compilation warnings about unexpected
serialization related method sign
Hi,
let's add an isEmpty default method to CharSequence!
Webrev: http://cr.openjdk.java.net/~redestad/8215401/open.00/
RFE:https://bugs.openjdk.java.net/browse/JDK-8215401
CSR:https://bugs.openjdk.java.net/browse/JDK-8215402
Testing: tier1-3
/Claes
Thanks Mark! I missed that, and I was also 20 min too fast on the
checkin :-)
Here's a catch-up patch, pls review:
http://cr.openjdk.java.net/~joehw/jdk15/8245231/webrev/
-Joe
On 5/18/2020 10:21 AM, mark sheppard wrote:
Hi Joe,
do your changes warrant a java doc change for readObject
in ea
HI,
Here’s an update of the API and implementation webrevs based on (mostly) API
feedback. We have removed the performance tests to make the review easier
(those will be dealt with separately to integration as a follow on task).
I think over the past year and recently via the CSR the API has ha
Hi Joe,
do your changes warrant a java doc change for readObject
in each LocPathIterator PredicatedNodeTest, and UnionPathIterator ?
regards
Mark
From: core-libs-dev on behalf of Joe
Wang
Sent: Friday 15 May 2020 17:54
To: core-libs-dev@openjdk.java.net
Sub
Hi Joe,
Looks good, thanks for the cleanup.
Roger
On 5/15/20 2:39 PM, naoto.s...@oracle.com wrote:
+1
Naoto
On 5/15/20 11:35 AM, Lance Andersen wrote:
Looks ok joe
On May 15, 2020, at 1:54 PM, Joe Wang wrote:
Hi,
Please review a fix for the compilation warnings. Thanks Roger for
the
On 5/18/20 11:11 AM, Alan Bateman wrote:
On 18/05/2020 09:59, Peter Levart wrote:
:
Please elaborate. Do you have an example of such use case? Are there
any existing races possible?
Everywhere that closes a file descriptor needs to coordinate the
closing with threads that may be accessing t
On 2020-05-18 11:11, Alan Bateman wrote:
On 18/05/2020 09:59, Peter Levart wrote:
:
Please elaborate. Do you have an example of such use case? Are there
any existing races possible?
Everywhere that closes a file descriptor needs to coordinate the closing
with threads that may be accessing
On 18/05/2020 09:59, Peter Levart wrote:
:
Please elaborate. Do you have an example of such use case? Are there
any existing races possible?
Everywhere that closes a file descriptor needs to coordinate the closing
with threads that may be accessing that file descriptor, otherwise you
risk doi
On 5/18/20 10:52 AM, Alan Bateman wrote:
On 18/05/2020 09:48, Peter Levart wrote:
Hi Claes,
One step further would be to eliminate access to
FileDescriptor.fd/handle from native hot paths altogether and pass
the fd/handle to native methods from java:
I was chatting with Claes about this la
On 18/05/2020 09:48, Peter Levart wrote:
Hi Claes,
One step further would be to eliminate access to
FileDescriptor.fd/handle from native hot paths altogether and pass the
fd/handle to native methods from java:
I was chatting with Claes about this last week and the concern with
doing this is
Hi Claes,
One step further would be to eliminate access to
FileDescriptor.fd/handle from native hot paths altogether and pass the
fd/handle to native methods from java:
http://cr.openjdk.java.net/~plevart/jdk-dev/8244936_dont_access_FileDescriptor/webrev.01/
This has similar incremental e
20 matches
Mail list logo
