Hello,
I would say the text in question is a (slightly incorrect) attempt to
provide some explicit informative implications of the preceding
normative text of the spec, so a CSR is not required for this correction.
(There are other cases where a small correction would require a CSR.)
217 //If this is a USA test, then only the fraction of the expected
failures will occur; those which are both static and final. 218 if (fl
!= FieldLookup.MH_UNREFLECT_SETTER_ACCESSIBLE &&
actualFieldNames.stream().anyMatch(s->!(s.contains("static")&&(s.contains("final")
What is a USA test?
PS Looking more closely, I see the the issue is addressed in the
01 version of the webrev; I was only looking at the 00 version before :-)
Thanks,
-Joe
On 3/21/2019 2:11 PM, Joseph D. Darcy wrote:
Hi Naoto,
Looks okay. The serial-related declarations are still using
; I think it is fine
Hi Naoto,
Looks okay. The serial-related declarations are still using
; I think it is fine to push what you have now, but what
encourage a follow-up bug to replace foo with {@code foo}
throughout the entire class.
Thanks,
-Joe
On 3/21/2019 1:54 PM, Naoto Sato wrote:
Hello,
Please review
+1
And I don't think a CSR is warranted, The text being modified
does not change the behavior, it makes a statement about what
the method does not do. (Which is pretty obvious).
Roger
On 03/21/2019 03:23 PM, Lance Andersen wrote:
+1
On Mar 21, 2019, at 3:05 PM, Brian Burkhalter
wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8220224
Here is the CSR and proposed changeset:
https://bugs.openjdk.java.net/browse/JDK-8220728
http://cr.openjdk.java.net/~naoto/8220224/webrev.01/
DecimalFormatSymbols assumes
+1
> On Mar 21, 2019, at 3:05 PM, Brian Burkhalter
> wrote:
>
> Please review this trivial fix for [0]:
>
> @@ -237,7 +237,7 @@
> * b[off+len-1] unaffected.
> *
> * In every case, elements b[0] through
> - * b[off] and elements b[off+len] through
> + * b[off-1] and
Please review this trivial fix for [0]:
@@ -237,7 +237,7 @@
* b[off+len-1] unaffected.
*
* In every case, elements b[0] through
- * b[off] and elements b[off+len] through
+ * b[off-1] and elements b[off+len] through
* b[b.length-1] are unaffected.
*
*
Hi Bob,
It looks good to me.
Thanks,
Serguei
On 3/21/19 10:12, Bob Vandette wrote:
Please review this fix for a container test that fails on some Linux
distributions.
The test fails to see the Memory Fail count metric value increase. This is
caused by
the fact that we are allowing
Done:
8221267[1] : Document the
jdk.net.URLClassPath.showIgnoredClassPathEntries system property
Thanks,
-Brent
1. https://bugs.openjdk.java.net/browse/JDK-8221267
On 3/20/19 5:28 PM, Mandy Chung wrote:
Hi Brent,
The change looks fine.
Can you file a JBS issue to follow up a place to
Hi Bob,
On Thu, 2019-03-21 at 13:12 -0400, Bob Vandette wrote:
> WEBREV:
>
> http://cr.openjdk.java.net/~bobv/8220674/webrev/
This looks good to me. Thanks for fixing it! I'm not a Reviewer,
though.
Cheers,
Severin
Please review this fix for a container test that fails on some Linux
distributions.
The test fails to see the Memory Fail count metric value increase. This is
caused by
the fact that we are allowing ergonomics to select the amount of Heap size.
This
size varies depending on the amount of
I think you missed HelpResources_zh_CN.properties
I think wording of help text: 'sub-path of the installation location of
the application such as"Program Files" or "AppData"' is misleading. It
reads like "Program files" or "AppDAta" are examples of the sub-path.
The error message says:
Hi Mandy,
Good spot. Have updated the webrev.
http://cr.openjdk.java.net/~afarley/8216558/webrev/
Could you review the proposed change?
Also, I ran the invoke tests as advised, and the only one that
fails is "LFGarbageCollectedTest.java", which also fails in the
same way when run against a
- Mail original -
> De: "Peter Levart"
> À: "Remi Forax" , "Brian Goetz"
> Cc: "core-libs-dev"
> Envoyé: Jeudi 21 Mars 2019 15:54:21
> Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams
> On 3/21/19 2:17 PM, fo...@univ-mlv.fr wrote:
>> for some reason i was
On 20/03/2019 21:01, Brent Christian wrote:
Hi,
JDK-8216401[1][2] added code to improve JAR spec conformance (WRT
relative URLs in the Class-Path attribute), while maintaining some key
compatibility aspects (entries using "file:" URLs are not relative,
but are used by some libraries).
This
+1 from me.
http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/
AbstractValidatingLMF
-
I see you renamed most of the fields and params. Most of these are
improvements, but it may be worth being more explicit in ambiguous
cases. For example, there are two method
On 3/21/19 2:17 PM, fo...@univ-mlv.fr wrote:
for some reason i was convinced that IntStream.iterator() was returning a
PrimitiveIterator.OfInt and not an Iterator,
so yes, it will work but i don't understand why it's not BaseStream instead of
Stream that inherits from Iterable.
I think
> On Mar 20, 2019, at 11:22 PM, Mandy Chung wrote:
>
> On 3/20/19 9:03 PM, Dan Smith wrote:
>> http://cr.openjdk.java.net/~dlsmith/8174222/webrev.00/
>
> AbstractValidatingLambdaMetafactory.java
> +throw new LambdaConversionException("implementation is not
> direct or cannot be
Hi Alan + Christoph, coming back to
https://bugs.openjdk.java.net/browse/JDK-8218547 .
We wanted to check for the whole flow (in JLI_Open on Windows ) , e.g.
checking whether only CreateFileW can be used instead of open.
I think there is already a similar solution available in the
- Mail original -
> De: "Brian Goetz"
> À: "Remi Forax" , "Stuart Marks"
> Cc: "core-libs-dev"
> Envoyé: Mardi 19 Mars 2019 00:58:04
> Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams
>> My fear is more than we will want in the future to have one code for
21 matches
Mail list logo
