be null.
I made this change in the test comment [2]
Thanks, Roger
Thanks,
Vicente
[1] https://bugs.openjdk.java.net/browse/JDK-8223803
[2] http://cr.openjdk.java.net/~vromero/8223914/webrev.01/
On 05/17/2019 12:55 PM, Vicente Romero wrote:
Please review simple fix for [1] at [2] plus the CS
thanks for the review,
Vicente
On 5/20/19 2:09 PM, Roger Riggs wrote:
Hi Vicente,
Looks ok.
Can you ident the 2nd and subsequent lines of the javadoc tag,
as is done in the other tags of the method.
No need for another webrev.
Thanks, Roger
On 05/20/2019 01:07 PM, Vicente Romero wrote:
how
Hi Jim,
Some minor comments:
- the javadoc for String::stripIndent needs some formating. There is a
solitary "counted. The"
- at method String::stripIndent, you can bail out and do nothing if
outdent==0
- suggestion: method String::outdent could return a MapInteger> to indicate the first index
Hi,
On 5/21/19 2:37 PM, Jim Laskey wrote:
On May 21, 2019, at 3:27 PM, Vicente Romero wrote:
Hi Jim,
Some minor comments:
- the javadoc for String::stripIndent needs some formating. There is a solitary
"counted. The"
Looking for a code review at this point. Will get to API so
Please review fix for [1] at [2] and the CSR at [3]. This is a simple
fix that is just rewording an assertion at method
java.lang.constant.DynamicCallSiteDesc::withArgs. The fix is simply:
diff -r dd321e3596c0 -r 78f3b29fb255
src/java.base/share/classes/java/lang/constant/DynamicCallSiteDesc.j
Please review fix for [1], at [2]. The implementation of method
MethodTypeDesc.resolveConstantDes is not in sync with its specification.
In particular where it says [3]:
Resolves this descriptor reflectively, emulating the resolution behavior
of JVMS 5.4.3 and the access control behavior of JV
Thanks Mandy, I will fix this in my local copy,
Vicente
On 6/25/19 10:37 AM, Mandy Chung wrote:
Hi Vicente,
This looks fine.
Nit: the new test line 71 and 80 have an extra space "Error (" that
can be taken out.
Mandy
On 6/24/19 8:33 PM, Vicente Romero wrote:
Please review fix f
looks good,
Vicente
On 9/9/19 5:03 PM, Mandy Chung wrote:
MethodType::fromMethodDescriptorString default to use the system class
loader in resolving classes per the given descriptor string if the
loader parameter is null. Since this method accesses the system class
loader on behalf of the calle
Hi all,
Please review the serialization changes to support records.
Thanks,
Vicente
http://cr.openjdk.java.net/~vromero/records.review/serialization/webrev.00/
Hi,
Please review the draft of the CSR for Core-libs support for records at [1]
Thanks,
Vicente
[1] https://bugs.openjdk.java.net/browse/JDK-8233436
Hi,
Please review the draft of the CSR for javax.lang.model support for
records at [1]
Thanks,
Vicente
[1]https://bugs.openjdk.java.net/browse/JDK-8233546
I have updated the CSR after some feedback, please take a look at it. I
have added some comments to the bug entry describing the last changes
Thanks,
Vicente
On 11/4/19 3:54 PM, Vicente Romero wrote:
Hi,
Please review the draft of the CSR for Core-libs support for records
at [1]
Thanks
/webrev.01/
On 11/20/19 6:26 PM, David Holmes wrote:
Hi Vicente,
On 21/11/2019 9:22 am, Vicente Romero wrote:
Hi David,
This is the list that appears in the `Discussion` tag in the JEP [1].
Sure but we're not discussing the JEP, this is now the RFR.
Cheers,
David
I will remove that refe
ges?
This removal seems okay, but I found one additional reference:
./src/utils/IdealGraphVisualizer/nbproject/project.properties:auxiliary.org-netbeans-modules-apisupport-installer.pack200-enabled=false
Thanks,
David
-
On 21/11/2019 8:54 am, Vicente Romero wrote:
Hi,
I need a reviewer for t
please wait, I found some additional dependencies on module jdk.pack,
will submit another webrev, sorry
Vicente
On 11/21/19 2:53 PM, Vicente Romero wrote:
Hi,
I think I have covered all the proposed fixes so far. This is the last
iteration of the webrev [1], all the current changes are in
, Vicente Romero wrote:
please wait, I found some additional dependencies on module jdk.pack,
will submit another webrev, sorry
Vicente
On 11/21/19 2:53 PM, Vicente Romero wrote:
Hi,
I think I have covered all the proposed fixes so far. This is the
last iteration of the webrev [1], all the current
Hi all,
On 11/22/19 3:21 AM, Alan Bateman wrote:
On 21/11/2019 19:53, Vicente Romero wrote:
Hi,
I think I have covered all the proposed fixes so far. This is the
last iteration of the webrev [1], all the current changes are in this
one, the code hasn't been split into different we
Hi,
Please review the code for the records feature at [1]. This webrev
includes all: APIs, runtime, compiler, serialization, javadoc, and more!
Must of the code has been reviewed but there have been some changes
since reviewers saw it. Also this is the first time an integral webrev
is sent ou
change at [1]
Thanks,
Vicente
[1] http://cr.openjdk.java.net/~vromero/records.review/all_code/webrev.01/
On 11/27/19 11:37 PM, Vicente Romero wrote:
Hi,
Please review the code for the records feature at [1]. This webrev
includes all: APIs, runtime, compiler, serialization, javadoc, and
more
onal to
full webrev would help track the incremental changes.
Thanks,
-Joe
On 11/28/2019 8:05 AM, Vicente Romero wrote:
Hi again,
Sorry but I realized that I forgot to remove some code on the
compiler side. The code removed is small, before we were issuing an
error if some serialization methods
hough I guess they
will come back at some point).
yes they will, I can remove them now but I guess we will need them once
we implement a lint warning
And, not sure what "get" and "set" are needed for?
removed
Maurizio
thanks,
Vicente
On 28/11/2019 16:05,
mment doesn't apply as there is no need for any
additional change. I have removed it
Jan
Thanks,
Vicente
On 28. 11. 19 5:37, Vicente Romero wrote:
Hi,
Please review the code for the records feature at [1]. This webrev
includes all: APIs, runtime, compiler, serialization, javadoc, and
by default in for the langtools tests, but
disabled by default elsewhere.)
HTH,
-Joe
On 11/29/2019 3:12 PM, Vicente Romero wrote:
Hi Joe,
All the tests that have an explicit -source 14 are that way because
of, I think to remember, a bug in jtreg that doesn't expand the
${some.pro
the review,
Vicente
-
On 28/11/2019 2:37 pm, Vicente Romero wrote:
Hi,
Please review the code for the records feature at [1]. This webrev
includes all: APIs, runtime, compiler, serialization, javadoc, and
more! Must of the code has been reviewed but there have been some
changes since
Hi,
Thanks a lot to all reviewers. This is the header of the changeset I'm
planning to push. There have been a ton of people working on the
development and / or the review process and I don't want to forget
anyone. Please let me know if I'm missing someone:
8225054: Compiler implementation f
Hi,
Please review the addition of some pack200 tests to the problem list.
They fail as the records patch adds new members to some visitors. But
there is less point on fixing them as pack200 will be removed.
diff -r 92385cd2429d test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt Wed Dec
thanks,
Vicente
On 12/4/19 2:20 PM, Joe Darcy wrote:
Looks fine Vicente; thanks,
-Joe
On 12/4/2019 11:19 AM, Vicente Romero wrote:
Hi,
Please review the addition of some pack200 tests to the problem list.
They fail as the records patch adds new members to some visitors. But
there is less
looks good,
Vicente
On 12/5/19 9:36 AM, Harold Seigel wrote:
Hi,
Please review this small change to simplify
Class.getRecordComponents() by changing the return type of
getRecordComponents0() to RecordComponent[].
Open Webrev:
http://cr.openjdk.java.net/~hseigel/bug_8235359/webrev/index.htm
looks good,
Vicente
On 12/5/19 1:08 PM, Joe Darcy wrote:
Hello,
Please review this small cleanup to records support in java.lang.Class:
JDK-8235369: "Class.toGenericString need to be updated for records"
CSR: https://bugs.openjdk.java.net/browse/JDK-8235428
webrev: http://cr.openjd
Please review the fix for [1] at [2] along with the corresponding CSR at
[3]. The fix pretends to clarify the specification for java.lang.Record.
Please see the CSR for more detail,
Thanks,
Vicente
PS, thanks to John Rose for proposing this fix
[1] https://bugs.openjdk.java.net/browse/JDK-823
sorry, I meant: "the fix attempts to clarify" instead of: "pretends to
clarify"
Vicente
On 2/4/20 3:38 PM, Vicente Romero wrote:
Please review the fix for [1] at [2] along with the corresponding CSR
at [3]. The fix pretends to clarify the specification for
java.lang.Re
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
record.
* @return a hash code value for this record.
Does it make sense to use a sole pattern in the descriptions?
Thanks,
Leonid
On 2/4/20 12:38, Vicente Romero wrote:
Please review the fix for [1] at [2] along with the corresponding CSR
at [3]. The fix pretends to clarify the specification f
record.
* @return a hash code value for this record.
Does it make sense to use a sole pattern in the descriptions?
Thanks,
Leonid
On 2/4/20 12:38, Vicente Romero wrote:
Please review the fix for [1] at [2] along with the corresponding CSR
at [3]. The fix pretends to clarify the specification f
Hi,
Please review the fix for issue [1]. The fix can be found at [2]. The
fix is minimal, reproduced below:
---
old/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/MessageImpl.java
2017-08-16 16:31:21.403085344 -0400
+++
new/src/java.xml.ws/share/classes/com/sun/xml/i
looks good,
Vicente
On 01/12/2018 07:31 PM, Kumar Srinivasan wrote:
Hello,
Could I get a review for this simple update to the 3rd party legal
(TPL) information.
Thanks
Webrev: http://cr.openjdk.java.net/~ksrini/8195072/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8195072
Curren
Please review the code for the second iteration of sealed classes. In this
iteration we are:
- Enhancing narrowing reference conversion to allow for stricter checking of
cast conversions with respect to sealed type hierarchies.
- Also local classes are not considered when determining implicitly
On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero wrote:
> Please review the code for the second iteration of sealed classes. In this
> iteration we are:
>
> - Enhancing narrowing reference conversion to allow for stricter checking of
> cast conversions with respect to sealed t
Please review this patch which modifies the spec for method
java.lang.Record::equals. It states that the implementation of this method
should use the record fields for the comparison instead of the accessors.
TIA,
Vicente
-
Commit messages:
- Merge branch 'master' into JDK-8257598
On Fri, 11 Dec 2020 02:07:50 GMT, Vicente Romero wrote:
> Please review this patch which modifies the spec for method
> java.lang.Record::equals. It states that the implementation of this method
> should use the record fields for the comparison instead of the accessors.
>
>
Please review this patch which modifies the spec for method
java.lang.Record::equals. It states that the implementation of this method
should use the record fields for the comparison instead of the accessors.
TIA,
Vicente
-
Commit messages:
- 8257598: Clarify what component values
On Fri, 11 Dec 2020 02:07:50 GMT, Vicente Romero wrote:
> Please review this patch which modifies the spec for method
> java.lang.Record::equals. It states that the implementation of this method
> should use the record fields for the comparison instead of the accessors.
>
>
On Fri, 11 Dec 2020 09:44:33 GMT, Chris Hegarty wrote:
> The change and test look good to me. Thanks Vicente.
>
> I have just one minor comment on the location of the test. I know there is
> not always a clear and clean separation across component areas, but another
> possible location, for yo
> Please review this patch which modifies the spec for method
> java.lang.Record::equals. It states that the implementation of this method
> should use the record fields for the comparison instead of the accessors.
>
> TIA,
> Vicente
Vicente Romero has updated the pull req
On Fri, 11 Dec 2020 05:02:25 GMT, Vicente Romero wrote:
> Please review this patch which modifies the spec for method
> java.lang.Record::equals. It states that the implementation of this method
> should use the record fields for the comparison instead of the accessors.
>
>
On Wed, 16 Dec 2020 09:41:47 GMT, Joel Borggrén-Franck
wrote:
> The fix for JDK-8256693 too often produces a ParameterizedType as the result
> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary
> only when this type or any of its transitive owner types has type paramete
On Wed, 16 Dec 2020 19:57:32 GMT, Joel Borggrén-Franck
wrote:
> Yes, not great, but at least it isn't brittle when running the test, only
> when changing it. I'd like to take a separate pass over the tests for 17 if
> possible.
what about declaring a static final field for that value instead
On Thu, 17 Dec 2020 10:07:13 GMT, Joel Borggrén-Franck
wrote:
>> The fix for JDK-8256693 too often produces a ParameterizedType as the result
>> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary
>> only when this type or any of its transitive owner types has type
>> p
Please review this simple fix that is removing the RECORDS enum constant from
the PreviewFeature.Feature enum, now that RECORDS are final in 16 this constant
can be safely removed.
Thanks,
Vicente
-
Commit messages:
- 8260959: remove RECORDS from PreviewFeature.Feature enum
Chang
On Thu, 25 Feb 2021 13:01:30 GMT, Adam Sotona wrote:
> Please review javap fix to handle java.lang.IllegalStateException for classes
> with invalid Signature attribute.
> New test (T8260403) parsing class with invalid Signature attribute (as
> described in the bug) is included.
> Fix wraps java
Please review this PR that intents to make sealed classes a final feature in
Java. This PR contains compiler and VM changes. In line with similar PRs, which
has made preview features final, this one is mostly removing preview related
comments from APIs plus options in test cases.
Thanks
--
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull request
On Fri, 16 Apr 2021 02:10:05 GMT, David Holmes wrote:
> Hi Vicente,
>
> Hotspot and hotspot tests all look fine. One query: why was this test removed?
>
> test/hotspot/jtreg/runtime/sealedClasses/AbstractSealedTest.java
>
> is that functionality tested elsewhere? (The other deleted test seemed
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull request
On Wed, 21 Apr 2021 14:42:39 GMT, Maurizio Cimadamore
wrote:
> Compiler changes look good (I have not checked SymbolGenerator).
>
> Why were some tests removed?
thanks for the review. The removed tests were already covered in langtools
regression tests, so I only removed duplicated tests
---
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull reques
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull reques
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull request
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull reques
On Mon, 17 May 2021 13:11:56 GMT, Adam Sotona wrote:
> Actual javap implementation reacts on corrupted TABLESWITCH or LOOKUPSWITCH
> bytecode instructions resulting to negative array allocation with
> NegativeArraySizeException, which is reported to user with stack trace and as
> serious inter
This is a very small patch that is just rewording the spec for
DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown if
the content of the argument is `null`
TIA for the review
-
Commit messages:
- 8224158: assertion related to NPE at DynamicCallSiteDesc::wit
On Mon, 17 May 2021 16:53:24 GMT, Vicente Romero wrote:
> This is a very small patch that is just rewording the spec for
> DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown
> if the content of the argument is `null`
>
> TIA for the review
ping
--
ases. Please also review the
> related [CSR](https://bugs.openjdk.java.net/browse/JDK-8265090)
>
> Thanks
>
> note: this PR is related to
> [PR-3528](https://github.com/openjdk/jdk/pull/3528) and must be integrated
> after it.
Vicente Romero has updated the pull reques
On Fri, 16 Apr 2021 01:08:57 GMT, Vicente Romero wrote:
> Please review this PR that intents to make sealed classes a final feature in
> Java. This PR contains compiler and VM changes. In line with similar PRs,
> which has made preview features final, this one is mostly removin
On Fri, 21 May 2021 08:53:51 GMT, Gavin Bierman wrote:
>> Hi all,
>>
>> Please review this patch to make the ConstantDesc hierarchy `sealed`, as was
>> promised in its Javadoc, now that sealed classes are finalising in JDK 17.
>>
>> Thanks,
>> Gavin
>
> Gavin Bierman has updated the pull requ
On Mon, 17 May 2021 16:53:24 GMT, Vicente Romero wrote:
> This is a very small patch that is just rewording the spec for
> DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown
> if the content of the argument is `null`
>
> TIA for the review
any rev
On Mon, 17 May 2021 16:53:24 GMT, Vicente Romero wrote:
> This is a very small patch that is just rewording the spec for
> DynamicCallSiteDesc::withArgs. Basically adding that NPE can also be thrown
> if the content of the argument is `null`
>
> TIA for the review
This pull
On Fri, 4 Jun 2021 09:46:31 GMT, Jan Lahoda wrote:
>> This is a preview of a patch implementing JEP 406: Pattern Matching for
>> switch (Preview):
>> https://bugs.openjdk.java.net/browse/JDK-8213076
>>
>> The current draft of the specification is here:
>> http://cr.openjdk.java.net/~gbierman/je
Please review this PR which is just syncing the implementation of
DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the
method's spec is that if the value of the `refKind` parameter is:
MethodHandleInfo.REF_invokeInterface, then
DirectMethodHandleDesc.Kind.valueOf(int, boole
On Wed, 9 Jun 2021 17:22:30 GMT, Mandy Chung wrote:
> Looks like the test does not verify the cases specified by `valueOf(int
> refKind, boolean isInterface)`.
> i.e. For most values of refKind, there is an exact match regardless of the
> value of isInterface except `REF_invokeStatic` and `REF_
dleDesc.Kind.valueOf(int, boolean) should be called with a
> value of `true` for its second argument, currently it is invoked with `false`
> regardless of the value of the `refKind` parameter
>
> TIA
Vicente Romero has updated the pull request incrementally with one additional
On Wed, 9 Jun 2021 17:22:30 GMT, Mandy Chung wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> addressing review changes
>
> test/jdk/java/lang/constant/MethodHandleDescTest.java l
This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416) which
was intended to openjdk/jdk.
Please review this PR which is syncing the implementation of
`DirectMethodHandleDesc.Kind.valueOf(int)` and
`DirectMethodHandleDesc.Kind.valueOf(int, boolean)` with its spec. My reading
On Tue, 8 Jun 2021 16:46:36 GMT, Vicente Romero wrote:
> Please review this PR which is just syncing the implementation of
> DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the
> method's spec is that if the value of the `refKind
On Thu, 10 Jun 2021 23:26:21 GMT, Vicente Romero wrote:
>> Please review this PR which is just syncing the implementation of
>> DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the
>> method's spec is that if the value of the
On Fri, 11 Jun 2021 15:01:20 GMT, Vicente Romero wrote:
> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416)
> which was intended to openjdk/jdk.
>
> Please review this PR which is syncing the implementation of
> `DirectMethodHandleDesc.Kind.va
On Fri, 11 Jun 2021 15:15:12 GMT, Vicente Romero wrote:
>> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416)
>> which was intended to openjdk/jdk.
>>
>> Please review this PR which is syncing the implementation of
>> `DirectMethodHan
is invoked with false
> regardless of the value of the refKind parameter
>
> TIA
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revision:
updating after review comments
-
Changes:
- all: https://git.openjdk
On Fri, 11 Jun 2021 18:17:10 GMT, Vicente Romero wrote:
>> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416)
>> which was intended to openjdk/jdk.
>>
>> Please review this PR which is syncing the implementation of
>> `DirectMethodHan
is invoked with false
> regardless of the value of the refKind parameter
>
> TIA
Vicente Romero has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request conta
is invoked with false
> regardless of the value of the refKind parameter
>
> TIA
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revision:
addressing review comments
-
Changes:
- all: https://git.openjdk
On Tue, 22 Jun 2021 00:45:36 GMT, Mandy Chung wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updating after review comments
>
> test/jdk/java/lang/constant/MethodHandleDes
On Fri, 11 Jun 2021 15:01:20 GMT, Vicente Romero wrote:
> This PR is a copy of [PR-4416](https://github.com/openjdk/jdk/pull/4416)
> which was intended to openjdk/jdk.
>
> Please review this PR which is syncing the implementation of
> `DirectMethodHandleDesc.Kind.va
Enum constant: jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES was not
removed when Sealed Classes were made final because the build was failing
without it. Now that the feature is final we should be able to safely removed
it. This is the intention of this patch.
TIA,
Vicente
On Wed, 23 Jun 2021 20:57:24 GMT, Vicente Romero wrote:
> Enum constant: jdk.internal.javac.PreviewFeature.Feature.SEALED_CLASSES was
> not removed when Sealed Classes were made final because the build was failing
> without it. Now that the feature is final we should be able to safel
Please review this PR that is fixing a mismatch between the implementation for
method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its
implementation. I made a mistake while working on a recent CSR
[JDK-8224985](https://bugs.openjdk.java.net/browse/JDK-8224985) and fixed the
API but m
On Mon, 12 Jul 2021 17:11:01 GMT, Mandy Chung wrote:
>> Please review this PR that is fixing a mismatch between the implementation
>> for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its
>> implementation. I made a mistake while working on a recent CSR
>> [JDK-8224985](https:/
nvoking. So it didn't make sense for the API of one method
> to be more restrictive than the other. Please review also the accompanying
> CSR.
>
> Thanks,
> Vicente
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revisio
nvoking. So it didn't make sense for the API of one method
> to be more restrictive than the other. Please review also the accompanying
> CSR.
>
> Thanks,
> Vicente
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revis
On Mon, 12 Jul 2021 18:06:30 GMT, Vicente Romero wrote:
>> Please review this PR that is fixing a mismatch between the implementation
>> for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its
>> implementation. I made a mistake while working on a recent CS
On Sat, 10 Jul 2021 19:03:36 GMT, Vicente Romero wrote:
> Please review this PR that is fixing a mismatch between the implementation
> for method `java.lang.constant.DynamicCallSiteDesc::withArgs` and its
> implementation. I made a mistake while working on a recent CSR
> [JDK-82
Please review this simple PR along with the associated CSR. The PR is basically
adding a line the the specification of method
`java.lang.runtime.ObjectMethods::bootstrap` stating under what conditions a
NPE will be thrown.
TIA
link to the [CSR](https://bugs.openjdk.java.net/browse/JDK-8272852)
(type);
requireNonNull(recordClass);
requireNonNull(names);
requireNonNull(getters);
will do, thanks,
Vicente
On 8/23/2021 4:04 PM, Brian Goetz wrote:
+1
On 8/23/2021 2:22 PM, Vicente Romero wrote:
Please review this simple PR along with the associated CSR. The PR
is basically adding a line the
://bugs.openjdk.java.net/browse/JDK-8272852)
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revision:
addressing review comments
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5226/files
- new: https://git.openjdk.java
On Mon, 23 Aug 2021 23:13:58 GMT, Mandy Chung wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> addressing review comments
>
> src/java.base/share/classes/java/lang/runtime/ObjectMe
On Wed, 25 Aug 2021 02:17:12 GMT, Mandy Chung wrote:
>> Hi Mandy, I have changed the implementation of the method to explicitly
>> require all arguments but lookup to be non-null as suggested by Brian. I
>> have also covered, I think, all the missing test cases in test
>> `ObjectMethodsTest`,
On 8/25/21 4:45 PM, Mandy Chung wrote:
On 8/25/21 12:08 PM, Vicente Romero wrote:
On Wed, 25 Aug 2021 02:17:12 GMT, Mandy Chung wrote:
Hi Mandy, I have changed the implementation of the method to explicitly require
all arguments but lookup to be non-null as suggested by Brian. I have
://bugs.openjdk.java.net/browse/JDK-8272852)
Vicente Romero has updated the pull request incrementally with one additional
commit since the last revision:
clarifying that the names parameter is ignored in some cases
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5
://bugs.openjdk.java.net/browse/JDK-8272852)
Vicente Romero has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains five additional
commits since the last re
On Mon, 30 Aug 2021 01:45:49 GMT, Mandy Chung wrote:
>> Vicente Romero has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> clarifying that the names parameter is ignored in some cases
>
> src/java.base/s
101 - 200 of 348 matches
Mail list logo
