Please review[2] and comment on a new Hex printing utility to support
OpenJDK tests.
The usefulness of a hex printing has been discussed from time to time with
many suggestions as to the API shape and features.
To get an idea of the API and features, take a look at the javadoc[1].
It covers the
unctionality is already included in that
webrev (I might've missed it), the hex printing in and of itself is valuable.
-Pavel
On 16 Apr 2020, at 20:17, Roger Riggs wrote:
Please review[2] and comment on a new Hex printing utility to support OpenJDK
tests.
The usefulness of a hex print
as you go?
Best
Lance
On Apr 16, 2020, at 3:17 PM, Roger Riggs <mailto:roger.ri...@oracle.com>> wrote:
Please review[2] and comment on a new Hex printing utility to support
OpenJDK tests.
The usefulness of a hex printing has been discussed from time to time
with
many suggestions
Hi Pavel,
Thanks for the scan of potential replacements.
I'll take a look and file followup issues for candidates for cleanup.
Some are going to be sensitive to the specific formatting.
Roger
On 4/17/20 11:36 AM, Pavel Rappo wrote:
On 17 Apr 2020, at 15:11, Roger Riggs wrote:
Hi Pavel
Hi Adam,
77-80: Simplify to just two cases, one for error=13 and another for error=2
static final String PERMISSION_DENIED_ERROR_MSG = "(Permission
denied|error=13)";
static final String NO_SUCH_FILE_ERROR_MSG = "(No such file|error=2)";
Regards, Roger
On 4/21/20 12:45 PM, Adam Farley8 wrote
e"
> To: Adam Farley8
> Cc: core-libs-dev , Roger Riggs
>
> Date: 21/04/2020 18:29
> Subject: [EXTERNAL] Re: RFR: 8239365: ProcessBuilder/Basic.java test
> modifications for AIX execution
>
> Hi Adam,
>
> I do not have strong emotions, leave it up to you. But did you
Ping...
I appreciate the comments about extending the functionality and uses and
will take them up as a separate enhancement.
A review would be appreciated.
Thanks, Roger
On 4/16/20 3:17 PM, Roger Riggs wrote:
Please review[2] and comment on a new Hex printing utility to support
OpenJDK
+1
On 4/27/20 12:36 PM, naoto.s...@oracle.com wrote:
Hello,
Please review this small doc fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8243664
Here is the diff:
---
--- old/src/java.base/share/classes/java/text/CompactNumberFormat.java
2020-04-27 09:09:14.0 -
+1,
BTW, Stuart you are a Reviewer, no need for a 2nd.
Roger
On 5/1/20 12:02 AM, Stuart Marks wrote:
Hi Jay,
OK, welcome! I'll sponsor this changeset for you. It's pretty simple,
so I'll just paste the exported changeset below. (For complicated
changesets, you'll have to ask a sponsor to h
Hi Michael,
Looks good.
Maybe just a future cleanup to rename files, since the "...so..." is
refering to solaris.
src/java.base/unix/native/libjli/java_md_solinux.h
src/java.base/unix/native/libjli/java_md_solinux.h
Regards, Roger
On 5/4/20 4:49 AM, Alan Bateman wrote:
On 04/05/2020 06:12
Hi Naoto,
Looks fine with a small source edit below.
TestUnicodeExtension.java: Please wrap the excessively long lines;
string concatination will put them together for the test.
Thanks, Roger
On 5/6/20 4:44 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following iss
Looks good, thanks
On 5/7/20 12:06 PM, naoto.s...@oracle.com wrote:
Hi Roger,
Thank you for the review. Wrapped the long lines as suggested, along
with some typo fixes in the comments:
https://cr.openjdk.java.net/~naoto/8244245/webrev.01/
Naoto
On 5/7/20 7:43 AM, Roger Riggs wrote:
Hi
Hi Naoto,
Looks fine.
Lots of small changes but mostly in the Unicode reference files.
Thanks, Roger
On 5/7/20 5:59 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8239383
Its CSR and proposed changeset are loca
Hi Claes,
Looks fine.
Straightfoward since the offiset is already cached for other operations.
Thanks, Roger
On 5/13/20 11:44 AM, Claes Redestad wrote:
Hi,
compilers can't see though and optimize away the repeated GetObjectField
calls in places such as in the io_util_md.h GET_FD macro:
#def
Hi Pavel,
No problem with the "with" -> "by" changes.
javax/naming/NameNotFoundException.java: 55
"initialized" -> "are initialized"
java/util/jar/Attributes.java:594
The period was in the correct place.
The second sentence is a separate comment about the use (non-use).
"used for the ex
Hi Pavel,
Yes, I think that would be an improvement.
But its a slippery slope beyond what you originally observed and wanted
to fix.
Thanks, Roger
On 5/15/20 11:59 AM, Pavel Rappo wrote:
On 15 May 2020, at 16:53, Roger Riggs wrote:
Hi Pavel,
No problem with the "with" ->
vel
On 15 May 2020, at 17:34, Roger Riggs wrote:
Hi Pavel,
Yes, I think that would be an improvement.
But its a slippery slope beyond what you originally observed and wanted to fix.
Thanks, Roger
On 5/15/20 11:59 AM, Pavel Rappo wrote:
On 15 May 2020, at 16:53, Roger Riggs wrote:
Hi Pavel,
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
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
Hi Claes,
Looks good, Thanks for the test.
p.s. I probably would have used a data provider for the CS cases but
its not significant.
On 5/19/20 6:37 AM, Claes Redestad wrote:
Hi Roger,
sure, added Emptiness.java with a few sanity tests.
/Claes
On 2020-05-19 00:29, Roger Riggs wrote:
Hi
Hi,
How does the performance degrade when the computation of the hash
is non-trivial. For example, with an array as a key or an object with
fields that are objects?
The original code made a point of computing the hash only once.
??, Roger
On 5/19/20 3:21 PM, Claes Redestad wrote:
Thanks for
Hi,
Right, its only in the case of removing the node because the new value
was null.
Besides being infrequent, that should not be a problem.
Thanks, Roger
On 5/19/20 3:56 PM, Christoph Dreis wrote:
Hi Roger,
How does the performance degrade when the computation of the hash
is non-trivial.
Looks fine.
On 5/20/20 5:31 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8239480
The proposed changeset, and the release note draft are located at:
https://cr.openjdk.java.net/~naoto/8239480/webrev.00/
https://
Hi Rob,
Thanks for the report, an issues has been created:
https://bugs.openjdk.java.net/browse/JDK-8245694
Regards, Roger
On 5/23/20 3:13 PM, Rob Spoor wrote:
Hi,
I was working on upgrading a library of mine from Java 8 to 11, and I
noticed my unit tests started failing. Some investigation
Looks good.
Thanks to Mark and you for the improvement and testing.
On 5/26/20 12:59 AM, David Holmes wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8242504
webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/
This work was contributed by Mark Kralj-Taylor:
https://mail.openjdk
+1,
Looks fine.
Should the benchmark be included?
Thanks, Roger
On 5/25/20 8:12 AM, Jim Laskey wrote:
+1
(Copyright date)
On May 25, 2020, at 7:02 AM, Claes Redestad wrote:
Hi,
sponsoring this patch from Christoph Dreis.
By pushing down the hash calculation we can optimize lookups
in
Hi Stuart,
Looks good.
rmid.properties: 134; avoid breaking "have\n been" in to separate lines.
I would break after the ",".
module-info.java: 35: "version" -> "release" for consistency across the
messages.
package-info.java: 41: "version" -> "release" and "it may" -> "may" to
be consist
Hi Jim,
This kind of code exists in other places too, trying to balance
preferred grow sizes
with necessary ones and implementation limits. The rationale and design has
been raised several times. That last time it resulting in consolidating
similar code
into jdk.internalutil.ArraysUppport.n
HI Jim,
StringJoiner.java: 173 and 241: put the OutOfMemoryException name on
the same line as the "new" (all one line).
Otherwise looks ok.
Thanks, Roger
On 6/1/20 3:51 PM, Jim Laskey wrote:
Thanks Martin.
On Jun 1, 2020, at 4:39 PM, Martin Buchholz wrote:
Missing "throw"; We should h
Hi Chris,
Looks good.
Thanks, Roger
On 6/2/20 12:54 PM, Chris Hegarty wrote:
This is a small change to ObjectInputStream, for 8238763 [1], to correctly
handle readUnshared for records.
Webrev:
https://cr.openjdk.java.net/~chegar/8238763/webrev.00/
-Chris.
[1] https://bugs.openjdk.java.
Hi Jim,
Given the infrequency of the exception messages being used,
can we simplify them and/or reuse the strings?
The stack trace would usually show what API was being used so I would
simplfy the messages to:
"exceeds implementation limit" or "size exceeds implementation limit".
Unsyn
Hi Claes,
Not a review...
You'll need a CSR for the API change.
FileSystem.java: You'll need proper javadoc for the new
getBooleanAttribute method.
6/11 is Rampdown Phase One (its a bit late for new APIs).
Regards, Roger
On 6/4/20 8:58 AM, Claes Redestad wrote:
Hi,
this patch proposes
Hi Claes,
Yep, my mistake, too many publics.
Thanks, Roger
On 6/4/20 9:25 AM, Claes Redestad wrote:
Hi Roger,
maybe I've missed something, but java.io.FileSystem is package-private
and not part of the public API. Is a CSR really required?
/Claes
On 2020-06-04 15:22, Roger Riggs wrote
On 2020-06-04 15:26, Alan Bateman wrote:
On 04/06/2020 14:22, Roger Riggs wrote:
Hi Claes,
Not a review...
You'll need a CSR for the API change.
FileSystem.java: You'll need proper javadoc for the new
getBooleanAttribute method.
FileSystem is not a public class so it's not a
hasBooleanAttributes(File f, int attributes) { 120
return (getBooleanAttributes(f) & attributes) == attributes; 121 }
Thanks, Roger
On 6/4/20 2:24 PM, Claes Redestad wrote:
Hi Roger,
On 2020-06-04 18:05, Roger Riggs wrote:
Hi Claes,
The code looks ok but I would rename the new metho
-05 11:23, Roger Riggs wrote:
Hi Claes,
Also, since the requested attribute is a bit mask the test should be
that all of the attributes are present, not just some, iIt might
prevent a mistake down the line.
Probably the method name and argument names should be plural.
Line: 120: should be
119
Hi Claes,
The new method name "argumentMistmatch" should be "argumentMismatch".
("Mis" vs "Mist").
The rest looks fine.
Roger
On 6/8/20 10:51 AM, Claes Redestad wrote:
Hi,
JDK-8246152 triggered a failure in a JCK test that expects a NPE
rather than a StringConcatException. We can keep th
Hi Peter,
I'd like to understand the scope and impact of the problem before
jumping to a solution.
For specific applications, overriding ObjectInputStream.resolveClass to
handle the class
lookup can handle the case as expeditiously as is necessary.
What application uses cases are impacted and
Hi Naoto,
Since the default locale is being changed even briefly, the test should
be run in /othervm.
Add: @run testng/othervm ...
DateTimeFormatter:1498:
Can the optimization be retained in the case where z.equals(zone)?
Move it down to 1508+ and check the zone vs z.
Thanks, Roger
Hi Naoto,
Looks fine.
fyi, Objects.equals(a,b) can replace DateTimeFormatter: 1510-1511.
Thanks, Roger
On 6/9/20 1:01 PM, naoto.s...@oracle.com wrote:
Hi Roger,
Thanks for the review.
On 6/9/20 8:52 AM, Roger Riggs wrote:
Hi Naoto,
Since the default locale is being changed even briefly
Hi,
All java.time instances are immutable and described as value based.
Identity based operations are defined as unpredictable and to be avoided.
(That specific text was omitted from DateTimeFormatter)
The test uses .equals so it is not depending on identity.
Roger
On 6/9/20 3:10 PM, naoto.s.
Please review cleanup to the test support for
jdk.test.lib.hexprinter.HexPrinter.
Correct issues with the test support for jdk.test.lib.hexdump.HexPrinter.
- Correct the swapped definitions of Formatters.ASCII and PRINTABLE
Printable should always return a single character,
ASCII provides
Thanks Lance
On 6/10/20 12:53 PM, Lance Andersen wrote:
Hi Roger,
I think your changes look fine.
Best
Lance
On Jun 9, 2020, at 6:47 PM, Roger Riggs <mailto:roger.ri...@oracle.com>> wrote:
Please review cleanup to the test support for
jdk.test.lib.hexprinter.HexPrinter.
Corre
Hi Jim,
In Unsafe.java: 632: the "Unable to allocate 98494837395: doesn't read
very well.
Please add " bytes" to the end.
I would probably drop "array" from all the messages but at least in the
String* cases.
As Martin notes, the array is an implementation detail.
(And i still prefer "implem
Hi Naoto,
The fix looks fine.
Thanks, Roger
On 6/10/20 3:49 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8246721
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8246721/webrev.00/
Th
Hi Naoto,
Yes, looks good.
Roger
On 6/12/20 1:06 PM, Lance Andersen wrote:
Hi Naoto,
This looks fine and looks like you are set with reviewers on your CSR
Best
Lance
On Jun 12, 2020, at 12:31 PM, naoto.s...@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://
to decide whether to use the Java platform for particular
tasks, and it would be unfortunate if we did not make the Java platform as
good as it could be.
... peter
-Original Message-
From: core-libs-dev on behalf of Roger Riggs
Organization: Java Products Group
Please review a test change of the test library HexPrinter.
It should be comparing against the System.lineSeparator.
diff --git a/test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java
b/test/lib-test/jdk/test/lib/hexdump/HexPrinterTest.java
--- a/test/lib-test/jdk/test/lib/hexdump/HexPrinterT
VM.latestUserDefinedLoader:390 caught my eye because it forces the
AppClassLoader.
It assumes that scanning the stack would find and return the
AppClassLoader, not so in all cases.
Regards, Roger
... peter
-----Original Message-
From: Roger Riggs
Organizatio
Looks fine.
On 6/17/20 2:44 PM, Martin Buchholz wrote:
8247782: typos in java.math
https://cr.openjdk.java.net/~martin/webrevs/jdk/math-spelling/
https://bugs.openjdk.java.net/browse/JDK-8247782
Hi Martin,
Looks fine,
I'm embarrassed by the one in the java.time tests, we should have known
better.
Thanks, Roger
On 6/17/20 3:22 PM, Martin Buchholz wrote:
No actual bugs fixed, but good to stamp out all instances of new Date(1970)
8247706: Unintentional use of new Date(year...) with
Hi Chris,
It may be prudent to check that the current value in the byte array is
the one you expect
before changing it.
That would help catch tests if something else changes the contents of
the stream.
Otherwise looks good.
Thanks, Roger
On 6/18/20 9:28 AM, Chris Hegarty wrote:
This is
Thanks Chris,
Looks good.
On 6/18/20 10:25 AM, Chris Hegarty wrote:
On 18 Jun 2020, at 14:56, Roger Riggs wrote:
Hi Chris,
It may be prudent to check that the current value in the byte array is the one
you expect
before changing it.
That would help catch tests if something else changes
al Message-----
From: Roger Riggs
Organization: Java Products Group, Oracle
Date: Tuesday, June 16, 2020 at 7:14 AM
To: "Peter Kessler (Open Source)" ,
"core-libs-dev@openjdk.java.net"
Subject: Re: [PATCH] 8246633: Improve the performance of
ObjectInputStream.resolveClass(Obj
Hi Raffaello,
I think the concern over accepting non-canonical encodings would be
compatibility.
It would rude to implement the strictness and have applications start
failing.
But it is likely an oversight since existing code checks for other
invalid encodings.
Do any of the existing tests f
Hi Raffaello,
Exceptions related to the arguments should be highest priority so they are
not obscured by any more dynamic state related to the stream.
There's no specific order between checks of the arguments,
though in this case the NPE would naturally occur before IOOBE.
There are more complex
Hi,
This is a case where having some more interoperability testing could be
informative
though there are likely many adhoc Base64 encoders and its not practical
to test
against them.
Introducing a new mode or option creates an undesirable fuzzyness to the
API.
It won't help existing uses w
Hi Mandy,
There may be a missing "to" in:
+ * Platform classes are visible the platform class loader
++ * Platform classes are visible *via* the platform class
loader
The second change seems to be self referential using "parent" to define
itself.
And pre-existing in the description
Hi Mandy,
I'm fine with this.
Roger
On 6/23/20 5:42 PM, Mandy Chung wrote:
On 6/23/20 12:01 PM, Roger Riggs wrote:
Hi Mandy,
There may be a missing "to" in:
+ * Platform classes are visible the platform class loader
++ * Platform classes are visible *via* the
Hi Ivan,
In test/jdk/java/util/jar/JarFile/JarBacktickManifest.java, I don't
think you want the new blank line
after the removed @summary.
Otherwise, looks fine.
Roger
On 6/30/20 5:15 PM, Brent Christian wrote:
Hi, Ivan
The changes look fine to me.
Please see that an automated test run th
Hi Raffaello,
There is way more code changed here than is needed to fix the bug.
General enhancement should be separated from bug fixes.
It makes it easier to review to see the bug was fixed
and easier to separately review other code to see that there are no
unexpected changes.
If some of the
Hi Raffaello,
I'm still not sure it needed this much of a re-write to fix the bug;
It will take some time to look at the changes.
Regardless, OpenJDK conventions call for following the style of the
existing code.
Your new comments follow neither the existing convention to use "//..."
comments
llo
[1]
https://www.oracle.com/java/technologies/javase/codeconventions-comments.html
On 2020-07-06 20:17, Roger Riggs wrote:
Hi Raffaello,
I'm still not sure it needed this much of a re-write to fix the bug;
It will take some time to look at the changes.
Regardless, OpenJDK conv
Please reveiw a change to increase the size of the Process Reaper stack
for debug builds.
This intermittent issue can be traced to the stack shadow page size
being larger
in debug builds than in release builds. The problem has only been
spotted in debug builds.
diff a/src/java.base/share/class
E.
harder: banish SOE in pure java code entirely by loomishly moving
continuations to a larger stack.
On Wed, Jul 8, 2020 at 1:54 PM Roger Riggs wrote:
Please reveiw a change to increase the size of the Process Reaper stack
for debug builds.
This intermittent issue can be traced to the stack sh
Roger,
Looks good to me.
Thanks,
David
On 9/07/2020 6:51 am, Roger Riggs wrote:
Please review a change to increase the size of the Process Reaper
stack for debug builds.
This intermittent issue can be traced to the stack shadow page size
being larger
in debug builds than in release builds. The pr
Looks good.
Though it does seem like the VM should have been able to reclaim enough
memory between tests
to not need to throw OOME.
Thanks, Roger
On 7/14/20 2:23 PM, Daniel D. Daugherty wrote:
On 7/14/20 2:09 PM, Jim Laskey wrote:
Adding Daniel
Begin forwarded message:
*From: *Jim Laske
Hi Naoto,
Given the extra tests in the body of the loop, I think its worth finding
or creating
a JMH test for this and checking the performance.
With performance in mind, I would try to fall back to the UC/LC
conversions only
when the bytes don't match. See java.util.Arrays.mismatch(byte[],
Hi Raffaello,
Base64.java:
2: Please update 2nd copyright year to 2020
leftovers():
996: "&" the shortcutting && is more typical in a condition.
997: the -= is buried in an expression and a reader might miss it.
1053: "can be reallocated to other vars": not a useful comment,
reflecting on o
Hi,
RMI DGC relies only on WeakReferences so unless that is disabled, RMI
should not see any difference.
The tests do provoke GC to run, so if it doesn't eventually clear weak
refs (within a timeout) that would fail.
Thanks, Roger
On 7/16/20 3:09 AM, Alan Bateman wrote:
On 15/07/2020 20:47,
.
I have also run the JCK tests in this area as well as mach5 tiers1-3
(which I believe Roger has also)
Best
Lance
On Jul 15, 2020, at 5:44 PM, Raffaello Giulietti
<mailto:raffaello.giulie...@gmail.com>> wrote:
Hi Roger,
On 2020-07-15 22:21, Roger Riggs wrote:
Hi Raffaello,
Base6
Hi Naoto,
StringUTF16.java:
343, 348: The masking and comparisons seem awkward.
I'd suggest just negating the value and testing for < 0 to flag the less
usual case.
If you continue with the flag bit, define your own static final constant
for that bit;
It looks odd to be using Integer.MIN_VALU
Please review a change to the Process reaper thread initialization to
preemptively
make sure classes ThreadLocalRandom and ConcurrentHashMap are initialized.
From the stack overflow failures, it seems that the classes have not
been initialized
before they are used during processing the terminat
class ensures
initialization of the class. Just loading. But I think CHM is already
initialized at that time as it is used in ClassLoader to maintain
class loading locks (per class name).
Regards, Peter
On 7/22/20 4:51 PM, Roger Riggs wrote:
Please review a change to the Process reaper t
Hi Mandy,
Looks fine.
Roger
On 7/22/20 3:04 PM, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8022795/webrev.00/
A small improvement to the dynamic proxy generated method to have
ACC_VARARGS matching the method declared in a proxy interface if set.
If there are t
Hi Naoto,
Looks fine. (with Joe's suggestion)
On 7/22/20 4:20 PM, Joe Wang wrote:
Hi Naoto,
The change looks good to me. "supLower" is indeed super slow :-)
The only minor comment I have is that the compareCodePointCI method
performs toUpperCase unconditionally. That's not a problem for the
Hi Mandy,
Looks good.
On 7/22/20 6:40 PM, Mandy Chung wrote:
Please review the CSR: https://bugs.openjdk.java.net/browse/JDK-8249939
Thanks
Mandy
On 7/22/20 1:55 PM, Joe Darcy wrote:
Hi Mandy,
The behavior change looks okay; please file a CSR for this too.
Thanks,
-Joe
On 7/22/2020 12:04
sLoader to maintain class
loading locks (per class name).
Regards, Peter
On 7/22/20 4:51 PM, Roger Riggs wrote:
Please review a change to the Process reaper thread initialization to
preemptively
make sure classes ThreadLocalRandom and ConcurrentHashMap are
initialized.
From the stack overflo
_native_entry(Thread*)+0x116
On 7/22/20 9:16 PM, David Holmes wrote:
Hi Roger,
On 23/07/2020 12:51 am, Roger Riggs wrote:
Please review a change to the Process reaper thread initialization to
preemptively
make sure classes ThreadLocalRandom and ConcurrentHashMap are
initialized.
I don't
he problem
intermittently but it would take a HS engineer to figure it out.
For now, all I have is an avoidence attempt.
Thanks, Roger
On 7/22/20 9:46 PM, David Holmes wrote:
On 23/07/2020 11:27 am, Roger Riggs wrote:
Hi David,
It took some digging in the hs_err files and looking at a core dump
to
Webrev updated with Martin's suggestion:
http://cr.openjdk.java.net/~rriggs/webrev-stackoverflow-8249217-2/
Thanks, Roger
On 7/22/20 8:35 PM, Martin Buchholz wrote:
Roger: You're absolutely right! I should have looked.
On Wed, Jul 22, 2020 at 5:25 PM Roger Riggs wrote:
Hi Marti
Please review adding an intermittent test to the ProblemList.
The test java/lang/invoke/lambda/LambdaFileEncodingSerialization.java
has been failing
intermittently and fairly frequently. [1]
diff a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jd
Looks good, thanks
On 7/23/20 4:30 PM, Daniel D. Daugherty wrote:
Accidentally pushed send before I was done. Please ignore the previous
email...
Greetings,
I'm making another pass at reducing the noise in the JDK16 CI.
There are currently 34 sightings of this test failure since I filed
the
f Technical Staff |+1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
Sent from my iPad
On Jul 23, 2020, at 4:28 PM, Roger Riggs wrote:
Please review adding an intermittent test to the ProblemList.
T
Looks good Naoto.
Thanks, Roger
On 7/30/20 5:53 PM, naoto.s...@oracle.com wrote:
Hi,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8233048
The proposed chageset is located at:
https://cr.openjdk.java.net/~naoto/8233048/webrev.00/
java.time.temporal.
Hi Joe,
Looks fine.
Roger
On 8/5/20 7:37 PM, Joe Wang wrote:
Hello,
Please review a fix for the hashCode generation.
JBS: https://bugs.openjdk.java.net/browse/JDK-8246816
webrev: http://cr.openjdk.java.net/~joehw/jdk16/8246816/webrev/
Thanks,
Joe
+1
On 8/6/20 4:18 PM, naoto.s...@oracle.com wrote:
Hi Joe, thank you for looking it into further.
Yes, I agree the chances of collision is very rare, as sub-millisecond
difference in two objects. So fine with the version 01.
Naoto
On 8/6/20 12:18 PM, Joe Wang wrote:
Thanks Naoto, Roger for
on version 01.
Best,
Joe
On 8/6/20 1:29 PM, Roger Riggs wrote:
+1
On 8/6/20 4:18 PM, naoto.s...@oracle.com wrote:
Hi Joe, thank you for looking it into further.
Yes, I agree the chances of collision is very rare, as
sub-millisecond difference in two objects. So fine with the
version 01.
Na
Hi Naoto,
I think the issue would benefit from a comment describing the solution.
Its not clear how the code addresses the issue.
Thanks, Roger
On 8/17/20 7:42 PM, naoto.s...@oracle.com wrote:
Hi Joe,
It turned out that the previous fix did not address plural format
cases. That means that j
Hi Naoto,
CompactNumberFormat.java:
269: The field "placeHolders" should be named consistently with the
other holders of Patterns.
-> placeHolderPatterns
1632: missing space before ":"
2390: I'm not sure why the stream processing is preferable to a direct
forEach(...).
TestCompactPatte
Looks fine Julia
On 8/18/20 1:02 PM, Julia Boes wrote:
Hi,
The two changes below still need to be reviewed. Any takers?
Cheers,
Julia
---
old/src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java2020-08-14
23:55:41.953638446 +0530
+++
new/src/java.base/sha
Hi Corey,
For changes obviously performance motivated, it is conventional to run a
JMH perf test to demonstate
the improvement and prove it is worthwhile to add code complexity.
I don't see any existing Base64 JMH tests but they would be in the repo
below or near:
test/micro/org/openjdk/
33 AM, Roger Riggs wrote:
Hi Naoto,
CompactNumberFormat.java:
269: The field "placeHolders" should be named consistently with the
other holders of Patterns.
-> placeHolderPatterns
1632: missing space before ":"
2390: I'm not sure why the stream processing i
Please review a java.util.Hex API to encode and decode hexadecimal
strings to and from byte arrays.
Within the JDK and JDK tests there are multiple implementations to
encode and decode
hexadecimal strings to byte arrays. Hex encoders and decoders support
upper or lower case hexadecimal charact
Hi Chris,
Inlining and simplifying unparseSig(cl, sb) seems straightforward.
Though I wonder if performs differently than just calling
t.descriptorString()?
The first action of Class.descriptorString is to check for primitives
and return the basicTypeString
and if not a primitive it calls C
Hi Chris,
Thanks for the comments, I'll make the updates suggested.
Roger
On 8/20/20 11:33 AM, Chris Hegarty wrote:
On 19 Aug 2020, at 22:14, Roger Riggs wrote:
..
JavaDoc:
http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html
I like it Roger, very nice. A few
Hi Raffaello,
Will do, an oversight in updating the example.
Thanks, Roger
On 8/20/20 12:46 PM, Raffaello Giulietti wrote:
Hi Roger,
in the examples in the javadoc you might want to correct the first
argument to Hex.encoder and Hex.decoder to "," to be consistent with
the narrative.
Gre
Hi Christoph,
Looks good.
Note that Claes added the cases for Object.class and int.class
to maximize the performance of those common cases.
I'll sponsor the change.
Thanks, Roger
On 8/20/20 2:01 PM, Christoph Dreis wrote:
Hi Roger,
thanks for taking a look!
Though I wonder if performs di
e(SB, byte[])? Then
we don’t need to break the chain when appending many different things to a
StringBuilder.
Also, are prefix and suffix really useful? One can easily add them.
Thanks,
Max
On Aug 19, 2020, at 5:14 PM, Roger Riggs wrote:
Please review a java.util.Hex API to encode and decode h
Hi Mark,
On 8/20/20 3:10 PM, mark.reinh...@oracle.com wrote:
2020/8/19 14:14:56 -0700, roger.ri...@oracle.com:
Please review a java.util.Hex API to encode and decode hexadecimal
strings to and from byte arrays.
JavaDoc:
http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.htm
1 - 100 of 3271 matches
Mail list logo
