On 09/12/2019 20:10, Brent Christian wrote:
Hi,
As discussed[1] last month on this alias, JAR Class-Path entries[2]
that encode an absolute Windows path (including a drive letter, so
e.g. "/C:/path/to/file.jar") are ignored as of 8211941.
Such entries are legal relative URLs, and should not
On 09/12/2019 23:17, Andy Herrick wrote:
Please review simple jpackage fir for issue [1] at [2]
transformFrom is not guaranteed to transfer all bytes so you can't
ignore the return value. I assume you could replace move/all of this
with a Files.copy that specifies REPLACE_EXISTING and COPY_ATTR
+1
-Phil.
> On Dec 9, 2019, at 2:36 PM, Alexander Matveev
> wrote:
>
> Looks good.
>
> Thanks,
> Alexander
>
>> On 12/9/2019 1:42 PM, Andy Herrick wrote:
>> Please review simple fix [2] for jpackage bug [1]
>>
>> fixing error message for mutually exclusive options.
>>
>> /Andy
>>
>> [1] h
Hi all,
May I get reviews for the small fix?
JBS: https://bugs.openjdk.java.net/browse/JDK-8235625
Webrev: http://cr.openjdk.java.net/~jiefu/8235625/webrev.00/
Thanks a lot.
Best regards,
Jie
+1
-phil.
On 12/9/19, 5:26 PM, Andy Herrick wrote:
On 12/9/2019 6:53 PM, Phil Race wrote:
> [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/
This does not bring up the expected webrev
My apologies - I uploaded the wrong webrev - It should be fixed now.
/Andy
-phil.
On 12/9/1
Hi Andy,
Looks good.
Thanks,
Alexander
On 12/9/2019 5:26 PM, Andy Herrick wrote:
On 12/9/2019 6:53 PM, Phil Race wrote:
> [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/
This does not bring up the expected webrev
My apologies - I uploaded the wrong webrev - It should be fixed n
On 12/9/2019 6:53 PM, Phil Race wrote:
> [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/
This does not bring up the expected webrev
My apologies - I uploaded the wrong webrev - It should be fixed now.
/Andy
-phil.
On 12/9/19 3:17 PM, Andy Herrick wrote:
Please review simple
Hi Joe,
The revised webrev looks good.
Side note on whether a private constructor should be empty or should throw some
Throwable. There are actually two (or more) use cases for private constructors:
1) intending to prevent instances from being created other than through
well-controlled APIs,
> [2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/
This does not bring up the expected webrev
-phil.
On 12/9/19 3:17 PM, Andy Herrick wrote:
Please review simple jpackage fir for issue [1] at [2]
/Andy
[1] https://bugs.openjdk.java.net/browse/JDK-8235601
[2] http://cr.openjdk.java
Please review simple jpackage fir for issue [1] at [2]
/Andy
[1] https://bugs.openjdk.java.net/browse/JDK-8235601
[2] http://cr.openjdk.java.net/~herrick/8235601/webrev.01/
/Andy
Looks good.
Thanks,
Alexander
On 12/9/2019 1:42 PM, Andy Herrick wrote:
Please review simple fix [2] for jpackage bug [1]
fixing error message for mutually exclusive options.
/Andy
[1] https://bugs.openjdk.java.net/browse/JDK-8234867
[2] http://cr.openjdk.java.net/~herrick/8234867/webrev.01
FYI, a fix for this (8235361[1]) is in review:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-December/063934.html
-Brent
1. https://bugs.openjdk.java.net/browse/JDK-8235361
On 12/9/19 12:17 PM, Jonathan Gibbons wrote:
I note that javac now uses the same definition of tryResolveFile in
its handling of Class-Path manifest entries, and so the behavior for
the compiler and runtime should now be aligned.
Yay!
This patch looks good to me.
Mandy
-- Jon
On 12/09/2
+1
Mandy
On 12/9/19 1:34 PM, Joe Darcy wrote:
PS That should be
http://cr.openjdk.java.net/~darcy/8230771.1
Cheers,
-Joe
On 12/9/2019 12:39 PM, Joe Darcy wrote:
Updated webrev:
http://cr.openjdk.java.net/~darcy/8230771.0/
Found a class extending Modifier to the the static definit
Hi Henry and Kumar,
Thank you again for the review! I have added the fix to isTerminalOpt and used
both of your suggestions to make new tests.
With native memory tracking enabled, I could actually see a crash on both Linux
and Windows without the suggested fix.
I tested the changes again on bo
Fine, thanks!
Raffaello
On 2019-12-09 22:30, Maurizio Cimadamore wrote:
Hi again,
after some offline discussions with the hotspot team, it became clear
that the recently added restriction on source/destination segments being
disjoint is redundant and that Unsafe::copyMemory can cope with ove
Please review simple fix [2] for jpackage bug [1]
fixing error message for mutually exclusive options.
/Andy
[1] https://bugs.openjdk.java.net/browse/JDK-8234867
[2] http://cr.openjdk.java.net/~herrick/8234867/webrev.01/
PS That should be
http://cr.openjdk.java.net/~darcy/8230771.1
Cheers,
-Joe
On 12/9/2019 12:39 PM, Joe Darcy wrote:
Updated webrev:
http://cr.openjdk.java.net/~darcy/8230771.0/
Found a class extending Modifier to the the static definitions; I
replaced this with a static import.
To
Hi again,
after some offline discussions with the hotspot team, it became clear
that the recently added restriction on source/destination segments being
disjoint is redundant and that Unsafe::copyMemory can cope with overlap.
For now I'l keep the API as is, but I will file a followup issue to
Updated webrev:
http://cr.openjdk.java.net/~darcy/8230771.0/
Found a class extending Modifier to the the static definitions; I
replaced this with a static import.
To make sure a class isn't instantiated, I usually have it throw
AssertionError or some exception, although as you say that i
+1
Paul.
> On Dec 9, 2019, at 11:23 AM, Maurizio Cimadamore
> wrote:
>
> Another iteration:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4/
>
> Delta of the changes since last version (v3) here:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4_delta/
>
> The java
I note that javac now uses the same definition of tryResolveFile in its
handling of Class-Path manifest entries, and so the behavior for the
compiler and runtime should now be aligned.
-- Jon
On 12/09/2019 12:10 PM, Brent Christian wrote:
Hi,
As discussed[1] last month on this alias, JAR Cl
Hi,
As discussed[1] last month on this alias, JAR Class-Path entries[2] that
encode an absolute Windows path (including a drive letter, so e.g.
"/C:/path/to/file.jar") are ignored as of 8211941.
Such entries are legal relative URLs, and should not be ignored. Please
review my fix to correct
Another iteration:
http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4/
Delta of the changes since last version (v3) here:
http://cr.openjdk.java.net/~mcimadamore/panama/8234049_v4_delta/
The javadoc has been updated inline here:
http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_
Oops, my bad, in my haste I misread the original code. (Effectively a reduction
on OptionalLong where empty dominates, but the code to write that is I think
less clear than the imperative loop.)
Paul.
> On Dec 7, 2019, at 11:02 AM, Maurizio Cimadamore
> wrote:
>
>
> On 06/12/2019 21:04, Pau
Hi Peter,
this looks like a clever optimization which basically takes advantage of
the fact that you can only access a segment if you are the same thread
as the segment owner. I think after we integrate, I'd love to give your
approach a try and see what happens performance-wise.
Right now we
It seems a bit overly cautious to throw AssertionError. JDK has many
private no-arg constructor and it can be as simple as empty
constructor. Just my preference.
Mandy
On 12/9/19 10:16 AM, Joe Darcy wrote:
Corrected patch:
diff -r 153e5f76551d
src/java.base/share/classes/java/lang/invoke/
Hi Letu,
Those translation drops are usually integrated at the end of the
development cycle, such as (for JDK 13):
https://bugs.openjdk.java.net/browse/JDK-8227009
And I don't think the issue is created for JDK 14 yet.
Naoto
On 12/9/19 10:04 AM, Yang, Letu wrote:
Thanks Naoto!
Is there a
Corrected patch:
diff -r 153e5f76551d
src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
---
a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
Mon Dec 09 23:00:13 2019 +0530
+++
b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
Mon
Hi Maurizio,
Nice work!
I see the API prefixes each independent access to memory with a call to
the following MemorySegmentImpl method:
157 @Override
158 public final void checkValidState() {
159 if (owner != Thread.currentThread()) {
160 throw new IllegalState
Thanks Naoto!
Is there a separate ticket for the translation to other locales?
Letu
On 12/4/19, 12:36 PM, "naoto.s...@oracle.com" wrote:
Looks good, assuming the change between 03 and 04 is to fix "no new line..."
Naoto
On 12/4/19 11:38 AM, Yang, Letu wrote:
> Hi Nao
+1
-phil
On 12/9/19, 6:33 AM, Andy Herrick wrote:
Please review this revised fix at [3].
This fix only adds "@modules jdk.incubator.jpackage" to junit.jar.
[3] http://cr.openjdk.java.net/~herrick/8235453/webrev.02/ /Andy
On 12/6/2019 1:33 PM, Andy Herrick wrote:
Please review this jpackager
Doh! Will correct. That is why I want to get the no-arg constructor
added as a javac warning (JDK-8071961) ;-)
Thanks all for catching this,
-Joe
On 12/9/2019 9:29 AM, Mandy Chung wrote:
Good catch! Daniel also pointed that out. I overlooked it. It needs
to add back a private no-arg constru
Good catch! Daniel also pointed that out. I overlooked it. It needs
to add back a private no-arg constructor.
Mandy
On 12/9/19 9:18 AM, Victor Williams Stafusa da Silva wrote:
If you remove the deprecated constructor, the compiler will add a
default one. Wouldn't it be a better idea to make
Hi Joe,
I'm sure I'm going to say something stupid but:
doesn't this adds back the public implicit no args constructors?
best regards,
-- daniel
On 08/12/2019 18:58, Joe Darcy wrote:
Hello,
Please review this small API changes for JDK 15:
JDK-8230771: Remove terminally deprecated con
If you remove the deprecated constructor, the compiler will add a default
one. Wouldn't it be a better idea to make the deprecated constructor
private and throwing an exception?
Em seg., 9 de dez. de 2019 às 14:13, Mandy Chung
escreveu:
> Looks good.
>
> Mandy
>
> On 12/8/19 10:58 AM, Joe Darcy
Looks good.
Mandy
On 12/8/19 10:58 AM, Joe Darcy wrote:
Hello,
Please review this small API changes for JDK 15:
JDK-8230771: Remove terminally deprecated constructors in java.base
CSR: https://bugs.openjdk.java.net/browse/JDK-8235548
webrev: http://cr.openjdk.java.net/~darcy/82307
Thanks Roger, I will address your comments.
Maurizio
On 09/12/2019 15:31, Roger Riggs wrote:
Hi,
Great work!
Comments, mostly related to readability: (Based on the 12/5 webrev)
FileChannelImpl.java:
1008-1009: else should be on the same line as }.
1124-1125: use Objects.requireNonNull(mode
Hi,
Great work!
Comments, mostly related to readability: (Based on the 12/5 webrev)
FileChannelImpl.java:
1008-1009: else should be on the same line as }.
1124-1125: use Objects.requireNonNull(mode, "mode");
1132-1144: odd mix of use of single line 'if' vs. with brackets. (yes,
its copy/pa
Please review this revised fix at [3].
This fix only adds "@modules jdk.incubator.jpackage" to junit.jar.
[3] http://cr.openjdk.java.net/~herrick/8235453/webrev.02/ /Andy
On 12/6/2019 1:33 PM, Andy Herrick wrote:
Please review this jpackager test fix for bug [1] at [2].
the fix adds "@require
This is a review request for a change to add a clarification to the
record related core reflection methods, that specifies what it means to
be a record class and access to the record components. Discussed
originally over on amber-spec-experts [1]
I expanded the existing record reflection test and
Daniel, Chris, Vyom,
Thanks for your comments and reviews!
About updating @bug tag: In general, I'm not adding the bug id if a fix
is for the test itself, i.e. bug has 'noreg-self' label.
- Aleksei
On 08/12/2019 20:33, Chris Hegarty wrote:
On 8 Dec 2019, at 10:48, Daniel Fuchs wrote:
Hi V
Yes, for bytes the 'swappiness' is redundant - that said, both the
layout API and the MemoryHandles API will still ask for endianness
regardless of the size, so having some extra (possibly redundant)
constants is good.
Also, as you might have noted from some of the comments on panama-dev,
we'
Hi Raffaello,
I think there is room to add more copy-related features in the future.
One thing to note, however: the rationale behind having a 'copy' method
is to expose a (safe) interface to the underlying Unsafe::copyMemory
method - which is an hotspot intrinsic, hence understood and optimize
Hi,
will there be a
MemoryAddress.move(MemoryAddress src, MemoryAddress dst, long bytes)
method with POSIX memmove(3) semantics at some point?
That would be useful, e.g., to "open a hole" into an array by shifting
existing elements towards higher indices (provided there's room).
MemoryAddre
45 matches
Mail list logo
