Hi,
Looks fine to me. I have just one minor observation:
src/java.base/share/native/libjli/emessages.h
*** 92,102
#define JRE_ERROR5 "Error: Failed to start a %d-bit JVM process
from a %d-bit JVM."
! #define JRE_ERROR6 "Error: Verify all necessary Java SE
components have bee
Hi, Philipp. Sorry for the further delay.
Just to step back a bit:
The current manifest-writing behavior dates back to JDK 1.2 (at least),
so compatibility is an overriding concern. It is unfortunate that
multi-byte characters weren't better accounted for in the placement of
line breaks fro
On 5/7/20 5:50 AM, Alan Bateman wrote:
On 07/05/2020 12:37, Johannes Kuhn wrote:
:
In the end, I don't know what causes the bug, or how I can replicate it.
I think I did find a likely suspect.
>
Good sleuthing. I don't what the conditions are for GetLocaleInfo to
fail but it does look like th
Looks good, Claes.
Just one small question:
src/java.base/share/classes/java/util/jar/JarFile.java
759 } catch (IOException | IllegalArgumentException ex) {
Why the addition of IllegalArgumentException ?
-Brent
On 5/10/20 2:07 PM, Claes Redestad wrote:
Hi Martin,
On 2020-05-10 21
Hi,
Please review this small fix in Windows native code:
Bug: https://bugs.openjdk.java.net/browse/JDK-8244767
Webrev: http://cr.openjdk.java.net/~bchristi/8244767/webrev-00/
As reported on this thread[1], the getEncodingInternal() function has a
potential unterminated string in the case th
20 7:47 AM, Johannes Kuhn wrote:
On 09-May-20 1:27, Brent Christian wrote:
On 5/7/20 5:50 AM, Alan Bateman wrote:
On 07/05/2020 12:37, Johannes Kuhn wrote:
:
In the end, I don't know what causes the bug, or how I can replicate
it.
I think I did find a likely suspect.
>
Good sleuthing
Thanks - change is pushed. -B
On 5/11/20 5:26 PM, [email protected] wrote:
+1
Naoto
On 5/11/20 5:25 PM, Brian Burkhalter wrote:
Hi Brent,
It looks OK to me.
Brian
On May 11, 2020, at 4:36 PM, Brent Christian
wrote:
Please review this small fix in Windows native code:
Bug
Hi,
Please review this change to remove the unused "getParent()" function
from jni_util_md.c on Windows.
https://bugs.openjdk.java.net/browse/JDK-8244855
Automated build+test job is in progress.
The diff is as follows:
diff -r ee4bd700b772 src/java.base/windows/native/libjava/jni_util_md.c
-
Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
[email protected]
Sent from my iPad
On May 12, 2020, at 3:05 PM, Brent Christian
wrote:
Hi,
Please review this change to remove the unused "getParent()" function
from jni_util_md.c
Hi, Jim
I have a few comments on the new wording (hopefully my understanding is
correct):
! * If the block ends with a LF{@code "\n"} or CR{@code "\r"}
character,
! * then this implies the block closes in column 0 of the next line,
and thus
! * implies an indent of 0.
I feel like th
ontains only a line
terminator." ?
or
* "...ignore the last line if the last line is empty (contains only a
line terminator)."
or something along those lines.
Thanks,
-Brent
On May 13, 2020, at 7:21 PM, Brent Christian wrote:
Hi, Jim
I have a few comments on the new wording
One comment:
src/java.base/share/classes/java/util/regex/Pattern.java
--- 1679,1690
i += 2;
int newTempLen;
try {
newTempLen = Math.addExact(j + 2, Math.multiplyExact(3,
pLen - i));
} catch (ArithmeticException ae) {
! thro
Thank you for submitting the fix, Yu Li. (And thanks for the sponsor,
Julia). This will be good to fix. I have a few changes to recommend.
src/java.base/share/classes/java/util/Properties.java
The code change looks fine to me.
The ending Copyright year just needs to be changed from 2019 ->
Looks good to me as well. Thanks for making the updates to the test case.
-Brent
On 6/8/20 2:38 AM, Julia Boes wrote:
Hi Yu Li,
The copyright year of Properties.java needs to be updated to 2020.
Otherwise looks good to me!
Cheers,
Julia
Hi, Mandy
For:
@@ -152,7 +152,7 @@
* The system class loader is typically used to define classes on the
* application class path, module path, and JDK-specific tools.
* The platform class loader is a parent or an ancestor of the
system class
- * loader that all platform c
Hi, Ivan
The changes look fine to me.
Please see that an automated test run that includes all the changed
tests is performed.
Thanks,
-Brent
On 6/30/20 5:38 AM, Ivan Sipka wrote:
Hi all,
kind reminder for RFR for JDK-8211974.
thank you,
- Original Message -
From: ivan.si...@oracle
Hi, Naoto
I have a few comments:
src/java.base/share/classes/java/lang/StringUTF16.java
379 private static int getSupplementaryCodePoint(byte[] ba, int cp,
int index, int start, int end)
I think it would be worth a small addition to the comment to reflect
that non-surrogate chars are re
Hi, Naoto
The latest changes look good to me.
-Brent
On 7/22/20 10:23 AM, [email protected] wrote:
Hi,
I revised the fix again, based on further suggestions:
https://cr.openjdk.java.net/~naoto/8248655.8248434/webrev.05/
Changes from v.04 are (all in StringUTF16.java):
- The short cut n
Looks good!
-Brent
On 8/6/20 3:54 PM, Brian Burkhalter wrote:
For [1], please review this trivial fix [2].
Thanks,
Brian
[1] https://bugs.openjdk.java.net/browse/JDK-8251272
[2] diff
--- a/src/java.base/share/classes/java/util/Formatter.java
+++ b/src/java.base/share/classes/java/util/Format
On Tue, 15 Sep 2020 12:39:11 GMT, Jaikiran Pai wrote:
>> Can I please get a review and a sponsor for this patch which fixes the issue
>> reported in
>> https://bugs.openjdk.java.net/browse/JDK-8244706?
>> The commit here sets the `OS` header flag to `255` (which represents
>> `unknown`) as note
On Wed, 23 Sep 2020 15:12:58 GMT, Jaikiran Pai wrote:
>> Can I please get a review and a sponsor for a fix for
>> https://bugs.openjdk.java.net/browse/JDK-8242882?
>>
>> As noted in that JBS issue, if the size of the Manifest entry in the jar
>> happens to be very large (such that it exceeds
>
On Wed, 23 Sep 2020 15:06:55 GMT, Jaikiran Pai wrote:
> Can I please get a review and a sponsor for a fix for
> https://bugs.openjdk.java.net/browse/JDK-8242882?
>
> As noted in that JBS issue, if the size of the Manifest entry in the jar
> happens to be very large (such that it exceeds
> the
Hi,
The java/util/prefs/AddNodeChangeListener.java test fails once in a while in
the automated test system. Previous
failures were traced to machine configuration errors, but that does not appear
to be the case this time.
My efforts to reproduce this failure have been unsuccessful. The only u
On Tue, 20 Oct 2020 23:25:31 GMT, Brian Burkhalter wrote:
>> Hi,
>>
>> The java/util/prefs/AddNodeChangeListener.java test fails once in a while in
>> the automated test system. Previous failures were traced to machine
>> configuration errors, but that does not appear to be the case this time
e we just
> need to sleep for longer to account for the occasional slower tier1 test run).
> * a few indentations fixes
>
> Thanks,
> -Brent
Brent Christian has updated the pull request incrementally with one additional
commit since the last revision:
print counter for sleeps
On Wed, 21 Oct 2020 20:39:18 GMT, Naoto Sato wrote:
> Hi,
>
> Please review the changes to the subject issue. The fix replaces the
> obsolete/incorrect English language/region/script display names in the COMPAT
> root locale bundle. The data are derived from CLDR's English names.
Hi, Naoto
W
On Wed, 21 Oct 2020 23:38:23 GMT, Naoto Sato wrote:
>> Hi,
>>
>> Please review the changes to the subject issue. The fix replaces the
>> obsolete/incorrect English language/region/script display names in the
>> COMPAT root locale bundle. The data are derived from CLDR's English names.
>
> Naot
On Wed, 21 Oct 2020 23:16:15 GMT, Naoto Sato wrote:
>> Hi, Naoto
>>
>> What is the source for the updated values in LocaleNames.properties?
>>
>> Also, could the bug synopsis be updated to be more descriptive?
>>
>> Thanks,
>> -Brent
>
> Hi Brent,
>
>> What is the source for the updated value
On Tue, 20 Oct 2020 21:49:37 GMT, Brent Christian wrote:
> Hi,
>
> The java/util/prefs/AddNodeChangeListener.java test fails once in a while in
> the automated test system. Previous failures were traced to machine
> configuration errors, but that does not appear to be the
On Fri, 23 Oct 2020 16:48:03 GMT, Naoto Sato wrote:
> Hi,
>
> Please review this small exception message fix.
>
> Naoto
Looks good.
-
Marked as reviewed by bchristi (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/841
There are a couple of stray " "'s in the StringBuilder.subSequence()
documentation, which should be removed. The updated doc build looks good.
-
Commit messages:
- remove nbsp from AbstractStringBuilder.subSequence()
Changes: https://git.openjdk.java.net/jdk/pull/963/files
Webrev
Using the {@systemProperty} tag for the "java.util.prefs.PreferencesFactory"
system property will allow it to be found in the main javadoc search index.
The updated doc build looks good.
-
Commit messages:
- 8214561: Use {@systemProperty} for definition of
java.util.prefs.Preferen
On Fri, 30 Oct 2020 19:38:45 GMT, Lance Andersen wrote:
>> There are a couple of stray " "'s in the StringBuilder.subSequence()
>> documentation, which should be removed. The updated doc build looks good.
>
> Looks fine Brent
Thanks, Lance
-
PR: https://git.openjdk.java.net/jdk/p
On Fri, 30 Oct 2020 19:30:14 GMT, Brent Christian wrote:
> There are a couple of stray " "'s in the StringBuilder.subSequence()
> documentation, which should be removed. The updated doc build looks good.
This pull request has now been integrated.
Changeset: 98a6
On Fri, 30 Oct 2020 19:47:14 GMT, Brent Christian wrote:
> Using the {@systemProperty} tag for the "java.util.prefs.PreferencesFactory"
> system property will allow it to be found in the main javadoc search index.
>
> The updated doc build looks good.
This pull request h
On Tue, 3 Nov 2020 00:04:58 GMT, Brian Burkhalter wrote:
> InputStream::readNBytes() invokes read(byte[],int,int) repeatedly to load
> bytes into a sequence of intermediate arrays. If an intermediate array is not
> completely filled before being added to the list of arrays the contents of
> wh
On Tue, 3 Nov 2020 08:56:38 GMT, Aleksey Shipilev wrote:
>> InputStream::readNBytes() invokes read(byte[],int,int) repeatedly to load
>> bytes into a sequence of intermediate arrays. If an intermediate array is
>> not completely filled before being added to the list of arrays the contents
>> o
On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato wrote:
> Hi,
>
> Please review the changes for upgrading the CLDR data to version 38. The vast
> majority of the changes are simply the changes in CLDR upstream, and others
> are mainly test changes due to the locale data change.
Changes seem fine
Hi, Roger.
The change looks good. I just noticed a couple small things:
2324 for (int i = 0; i < slots.length-1; i++) {
2325 new FieldValues(slots[i].desc, true);
The slots[i].hasData check is no longer performed here.
2561 primValues = new byte[desc.ge
Hi, Lance
This change is to collect more information in case this happens again, yes?
Looks pretty good - just a couple comments:
test/jdk/tools/jar/multiRelease/Basic.java
536 jar("ufm", jarfile, manifest.toString(),
Is there a reason not to convert this to call jarTool() ?
--
te
Thank you for elaborating. The new version looks good.
-Brent
On 5/30/19 1:29 PM, Lance Andersen wrote:
Hi Brent,
On May 30, 2019, at 4:02 PM, Brent Christian
mailto:[email protected]>> wrote:
Hi, Lance
Thank you for the review.
This change is to collect more informat
Hi, Ivan
The change looks fine.
I would call this "noreg-cleanup". Tests are needed to confirm the
correctness of the new code, which I imagine we already have.
One small suggestion:
src/java.base/share/classes/java/util/regex/Pattern.java
4271 * and unlimited maximum, for *, + and
Hi, Claes
I think the change looks fine. A couple suggestions:
---
src/java.base/share/classes/java/util/regex/Pattern.java
3505 public boolean is(int ch) {
Would it make sense to have @Override here?
4777 * The matchRef is used when a reference to this group is accessed later
4778
That looks fine, Ivan.
-Brent
On 6/24/19 10:46 PM, Ivan Gerasimov wrote:
Hello!
Would someone volunteer to review this extra-small doc-only fix?
Thanks in advance!
With kind regards,
Ivan
On 5/28/19 9:33 AM, Ivan Gerasimov wrote:
Hello!
When the fix for JDK-7039066 (which added support
I was musing about this myself. If the changes are within the
@implNote(s), then perhaps not?
-Brent
On 6/25/19 11:15 AM, Brian Burkhalter wrote:
>
Is a CSR in order?
Thanks,
Brian
On Jun 25, 2019, at 5:49 AM, Ivan Gerasimov wrote:
Hello!
Would someone volunteer to review this extra-sm
Hi,
Is the webrev incomplete? It only contains the changes for
DualPivotQuicksort.java, and not for Arrays.java, etc.
Thanks,
-Brent
On 6/18/19 2:37 PM, Vladimir Yaroslavskiy wrote:
Hi team,
Please review the final optimized version of Dual-Pivot Quicksort (ver.19.1),
see http://cr.openjdk
Thanks, Laurent. I can sponsor this fix, get a RFR thread going for
JDK-8226297, keep webrevs updated as the review progresses, etc.
However I've uncovered an issue with the fix that should be resolved
before proceeding.
Specifically, the new Arrays.COMMON_PARALLELISM static constant causes
Hi,
Please review Vladimir Yaroslavskiy's changes to DualPivotQuickSort
(seen earlier[1] on this alias). I will be sponsoring this change.
I have a webrev against jdk-jdk here:
http://cr.openjdk.java.net/~bchristi/8226297/webrev03-rfr/
(Note that I did a little re-ordering, and removed some
ed to compare your webrev against my latest (diff patch files) but
it gives me too many changes lines.
Do you have another idea to see incremental changes only ?
(anyway I can compare raw files)
Thanks,
Laurent
Le lun. 5 août 2019 à 23:43, Brent Christian <mailto:[email protected]>&g
that ordering, so that's
what I've done.
Thanks,
-Brent
Вторник, 6 августа 2019, 21:35 +03:00 от Brent Christian
:
Hi, Laurent
I'm not sure what exactly is causing the problem, but here's my hunch:
In Vladimir's version of Arrays.java:
Hi Claes,
Some observations:
394 int u1 = CharacterDataLatin1.instance.toUpperCase(c1);
395 int u2 = CharacterDataLatin1.instance.toUpperCase(c2);
Changing u1 & u2 from char -> int, L399 now calls toLowerCase(int)
instead of toLowerCase(char). Should be fine, though. Speaking of:
399 if
Hi,
I received an update from Vladimir:
---
"I investigated approach with adaptive threshold for mixed insertion sort
and have the following results.
New version shows the same gain for large arrays
and has few percents of speed up for small arrays:
total gain:
s
Hi,
Please review my fix for JDK-8212117[1]. The webrev is here:
http://cr.openjdk.java.net/~bchristi/8212117/webrev09/
There is also a CSR[2] in need of review.
The spec for the 2-arg and 3-arg Class.forName() methods states they
will "locate, load, and link" the class, however the linking
Hi, David
On 9/5/19 12:52 AM, David Holmes wrote:
Good to see this all come together :)
:)
So to clarify for others any current caller to
find_class_from_class_loader that passes true for "init" was already
implicitly asking for a linked class (as you must be linked before you
can be init
ction matches what is in the JLS.
Thanks,
-Joe
On 9/4/2019 2:12 PM, Brent Christian wrote:
Hi,
Please review my fix for JDK-8212117[1]. The webrev is here:
http://cr.openjdk.java.net/~bchristi/8212117/webrev09/
There is also a CSR[2] in need of review.
The spec for the 2-arg and
Hi, Mandy
On 9/5/19 6:03 PM, Mandy Chung wrote:
On 9/5/19 5:09 PM, Brent Christian wrote:
jvm.h
349 * Link the 'arg' class (unless ClassForNameDeferLinking is set)
I suggest to drop "(unless ...)" phrase because the flag is temporary.
Sure, good idea.
jni.cpp
T
Hi,
From the bug report:
"The ProblemList indicates that
vmTestbase/nsk/jdb/eval/eval001/eval001.java was added due to
JDK-8212117. That bug has been fixed, but this test still fails. That
line in the ProblemList should instead use 8221503."
The change is:
diff -r 85e1de070bef test/hotspot
Hi,
Please review these StackWalker and Throwable benchmarks for addition
into the JDK microbenchmarks.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8221623
Webrev:
http://cr.openjdk.java.net/~bchristi/8221623/webrev07/
The StackWalker benchmarks use StackWalker's forEach(), walk(), and
Opt
FWIW, I also noticed this for
http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/lang/SecurityManager.java.sdiff.html
-B
On 9/18/19 11:32 AM, [email protected] wrote:
Hi Julia,
This is not a comment to changes you've made, but the webrev seems
mi
erwise.
Thanks,
-Brent
On 9/18/19 11:37 AM, Brent Christian wrote:
FWIW, I also noticed this for
http://cr.openjdk.java.net/~jboes/webrevs/8231186/webrev.02/src/java.base/share/classes/java/lang/SecurityManager.java.sdiff.html
-B
On 9/18/19 11:32 AM, [email protected] wrote:
Hi Julia,
o setup more
practical JMH runtimes by default. But I don't think this an issue
particular the new benchmarks.
Thanks,
-Brent
On 9/18/19 7:33 PM, Mandy Chung wrote:
Hi Brent,
$ make test TEST="micro:java.lang.StackWalkBench"
It took very long that I killed the job. Does t
logging benchmarks to
their own file under:
test/micro/org/openjdk/bench/java/util/logging/
?
Thanks,
-Brent
On 13/09/2019 23:07, Brent Christian wrote:
Hi,
Please review these StackWalker and Throwable benchmarks for addition
into the JDK microbenchmarks.
Bug:
https://bu
Hi, Julia
On 9/20/19 3:22 AM, Julia Boes wrote:
Hi,
Thanks for noticing the glitch in the sdiffs, Naoto and Brent. I see
that there is indeed an issue with the webrev script and I'm looking
into a workaround.
The following classes are affected:
src/java.base/share/classes/java/lang/Securit
age" tension WRT what @Benchmark methods get included/run. Worth
giving thought to sometime...
On 2019-09-19 20:09, Brent Christian wrote:
Hi, Mandy
Yes, that 'make' job would take ~7 hours on my machine.
I believe this is typical for running micros using 'make'.
Looks good. -B
On 9/23/19 11:17 AM, Julia Boes wrote:
Hi Brent,
I was able to generate a webrev without any missing sdiffs (using gawk
instead of awk with webrev.ksh) and made the requested changes below.
src/java.base/share/classes/java/util/ResourceBundle.java
I believe the tag spanni
On 9/23/19 2:15 AM, Daniel Fuchs wrote:
>> ...
since logging is no longer using Throwable to examine
the call stack, maybe it makes more sense to move the logging
benchmarks to their own file under:
test/micro/org/openjdk/bench/java/util/logging/ >
Well, I'll let you decide on that. That woul
On 9/23/19 4:48 PM, Mandy Chung wrote:
I think doing the measurement for one of these would be adequate.
StackWalkBench.forEach_AllOpts
StackWalkBench.forEach_DefaultOpts
StackWalkBench.forEach_HiddenAndReflectFrames
OK, reduced to just DefaultOpts.
There are a couple of commented benchmark
Hi, Vladimir
I've read through the changes[1]. I have the following comments:
---
src/java.base/share/classes/java/util/Arrays.java
* Regarding the indentation changes in the equals() methods:
- * {@code new Double(d1).equals(new Double(d2))}
+ * {@code new Double(d1).equals(new D
On 10/7/19 1:12 AM, Alan Bateman wrote:
On 7/10/2019 4:43 pm, Alan Bateman wrote:
On 07/10/2019 04:35, David Holmes wrote:
You can temporarily workaround with
-XX:+ClassForNameDeferLinking, but your code needs to be
updated to deal with LinkageErrors from Class.forName. >>>
I suspect this
Hi, Vladimir
On 10/8/19 3:18 PM, Vladimir Yaroslavskiy wrote:
The following renaming changes are important
and should be kept. My explanation is here
> ...
Thanks for the explanation - much appreciated.
* Other changes, like failed -> fail, i++ -> ++i,
and TypeConverter, FloatBuilder, Doubl
Looks fine. You might consider s/separated/separately/ .
-Brent
On 10/18/19 1:56 PM, Mandy Chung wrote:
A trivial doc fix:
diff --git a/src/java.base/share/classes/java/lang/System.java
b/src/java.base/share/classes/java/lang/System.java
--- a/src/java.base/share/classes/java/lang/System.j
PM, Brent Christian wrote:
Looks fine. You might consider s/separated/separately/ .
-Brent
On 10/18/19 1:56 PM, Mandy Chung wrote:
A trivial doc fix:
diff --git a/src/java.base/share/classes/java/lang/System.java
b/src/java.base/share/classes/java/lang/System.java
--- a/src/java.base/sh
the change if that sounds good.
Other than those, this is pretty much ready to go.
Thanks,
-Brent
1. http://cr.openjdk.java.net/~bchristi/8226297/webrev09-incremental/
On 10/8/19 5:41 PM, Brent Christian wrote:
Hi, Vladimir
On 10/8/19 3:18 PM, Vladimir Yaroslavskiy wrote:
The following
Hi, Vladimir
I'd prefer to keep the code as is. Perhaps the exception could help
some other future maintainer to pinpoint a problem with a potential change.
-Brent
On 10/24/19 5:11 AM, Vladimir Yaroslavskiy wrote:
Hi Brent,
Looking at coverage of DualPivotQuicksort class, I found that
case
nline
Oct 24б 2019, 7:42 +03:00 от Brent Christian
:
Hi,
I've created a webrev of the latest test changes that Vladimir sent me:
http://cr.openjdk.java.net/~bchristi/8226297/webrev09-testUpdate/
(I also created an incremental webrev[1] along the way, in c
Hi,
Please review my change to backout JDK-8212117:
http://cr.openjdk.java.net/~bchristi/8233091/webrev-revert-01/
Background:
A couple months ago, JDK-8212117[1] was fixed[2]. It changed the
behavior of the 2-arg and 3-arg Class.forName methods to ensure that
linking is performed. This con
Hi, Naoto
Looks pretty good. I have a few comments:
--
src/java.base/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java
572 map = new HashMap<>();
FWIW, I believe the HashMap could be pre-sized using 'names.length'.
--
src/java.base/macosx/native
Looks good. -B
On 11/6/19 6:11 PM, [email protected] wrote:
Here is the updated webrev:
https://cr.openjdk.java.net/~naoto/8232871/webrev.01/
Should the new escapes be added to the table in the
String.translateEscapes() JavaDoc?
-Brent
On 11/7/19 6:22 AM, Jim Laskey wrote:
Please review the following code changes. Provides for the introduction of two new escape
sequences \ and \s. \ allows developers to
express unwieldy string li
Hi,
Recently, the 2-arg and 3-arg Class.forName() methods were updated[1] to
perform class linking, per the specification. However this change had
to be reverted[2].
Instead, let's clarify the Class.forName() spec not to guarantee linking
(outside the case of also performing initialization,
On 11/14/19 8:22 AM, Mandy Chung wrote:
On 11/13/19 10:37 AM, Brent Christian wrote:
The spec change looks fine.
OK, thanks.
As for the test, I expect that it simply calls Class.forName("Provider",
false, ucl) and then should succeed.
Then calling Class.forName("Provi
On 11/14/19 4:12 PM, David Holmes wrote:
On 15/11/2019 9:58 am, Brent Christian wrote:
http://cr.openjdk.java.net/~bchristi/8233272/webrev-03/
Test is fine. Just one note/clarification:
63 // Loading (but not linking) Container will succeed.
Container was already loaded as part
On 11/14/19 4:46 PM, Mandy Chung wrote:
On 11/14/19 4:42 PM, David Holmes wrote:
If you really want to test both positive and negative cases from a
clean slate then I would suggest modifying the test slightly and using
two @run commands - one to try to initialize and one to not.
Yes this is
Hi, Jim
src/java.base/share/classes/java/lang/String.java
These changes look fine.
--
test/jdk/java/lang/String/TranslateEscapes.java
I'm missing where the new verifyLineTerminator() method gets called.
Perhaps that's meant to go here:
83 static void test4() {
84
85 }
?
-B
Thank you for the suggestions, Mandy and David. I've pushed the change.
-Brent
On 11/18/19 6:26 AM, Jim Laskey wrote:
http://cr.openjdk.java.net/~jlaskey/8233116/webrev.04/index.html
OK, thanks.
The changes in:
src/java.base/share/classes/java/lang/String.java
test/jdk/java/lang/String/TranslateEscapes.java
look fine.
-Brent
On 11/18/19 7:36 AM, Alan Bateman wrote:
>
Yes, bad values are now ignored, bringing an end to an effort on the
run-time over multiple releases to fix the problems this area.
JDK-8224253[1] is the JDK 13 release note to announce this change and I
see you've found the system property that you ca
Hi, Jaikiran
On 11/18/2019 7:56 AM, Jaikiran Pai wrote:
The actual code which does this construction, resides here[2] .
I see at [3] that '/' is prepended to the path. As Alan suggested [4],
prepending with "file:/" ought to get it working.
-Brent
2.
https://github.com/quarkusio/quarkus/b
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
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
Looks reasonable to me - reviewed.
-Brent
On 1/6/20 10:29 AM, Jim Laskey wrote:
Please review the following CSR intended to clarify the true meaning of
StringBuilder::capacity and StringBuffer::capacity.
csr: https://bugs.openjdk.java.net/browse/JDK-8236683
diff --git a/src/java.base/share/c
Looks fine to me, Roger.
-Brent
On 1/24/20 11:51 AM, Roger Riggs wrote:
Please review a doc change in the description of the initialization of
the jdk.serialFilter from
a system property to generalize it beyond only command line invocation.
diff a/src/java.base/share/classes/java/io/ObjectInp
As a point of interest, some investigation of updating StringJoiner for
CompactStrings was done a while back.
See https://bugs.openjdk.java.net/browse/JDK-8148937
-Brent
On 2/3/20 2:38 PM, Сергей Цыпанов wrote:
Hello,
as of JDK14 java.util.StringJoiner still uses char[] as a storage of glued
Adding -XX:+CompactStrings seems reasonable to me. (And I think it's a
betters solution than, say, increasing -Xmx to allow running without
compact strings.)
-Brent
On 3/17/20 10:46 AM, Brian Burkhalter wrote:
OK, I am fine with that. I’ll leave it open for the moment though in case
anyone
On Thu, 19 Nov 2020 20:32:17 GMT, Roger Riggs wrote:
>> ObjectInputStream has nearly identical but separate implementations to read
>> values from the stream.
>> Both implementations read primitive and object values from the stream and
>> return an object holding the values.
>> OIS.readFields()
On Thu, 3 Dec 2020 19:10:46 GMT, Mandy Chung wrote:
> VarHandleTestByteArrayAsInt.java intermittently fails only fastdebug build
> and slow mac os machines. I can't reproduce this locally. It fails on jdk
> 16 internal testing on a few builds. I propose to increase the timeout and
> see if
Please review this fix for the intermittently-failing
java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java.
The change replaces System.gc()+sleep() with the more robust gcAwait() mechanic
used elsewhere in the test base, [as pointed out by
Martin](https://bugs.openjdk.java.net/browse/JDK-
On Fri, 4 Dec 2020 19:51:54 GMT, Mandy Chung wrote:
>> Please review this fix for the intermittently-failing
>> java/lang/ClassLoader/nativeLibrary/NativeLibraryTest.java.
>>
>> The change replaces System.gc()+sleep() with the more robust gcAwait()
>> mechanic used elsewhere in the test base,
> Martin](https://bugs.openjdk.java.net/browse/JDK-8200102?focusedCommentId=14382648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14382648)(thanks!).
>
> The new version of the test passes 100 times out of 100 on the test farm.
Brent Christian has updated the pull request w
On Mon, 7 Dec 2020 20:38:31 GMT, Naoto Sato wrote:
>> Brent Christian 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 contain
1 - 100 of 511 matches
Mail list logo
