Re: RFR [6968459] JNDI timeout fails before timeout is reached

Hello Ivan, Thanks for the updated patch. I would like to see a testcase along with this fix, since it is modifying a critical component of the LDAP client code. An LDAP server may not even be required in order to exercise the timeouts. Thanks. On 3 Dec 2013, at 14:35, Ivan Gerasimov

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

Fix looks fine. You just need to update the import statements in Obj.java On 19 Mar 2014, at 18:37, Mandy Chung mandy.ch...@oracle.com wrote: https://bugs.openjdk.java.net/browse/JDK-8035807 Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/ This patch

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

OK. Thanks. On 19 Mar 2014, at 19:06, Mandy Chung mandy.ch...@oracle.com wrote: On 3/19/2014 12:03 PM, Vincent Ryan wrote: Fix looks fine. You just need to update the import statements in Obj.java Fixed. Not sure how it's missed in the webrev :) thanks Mandy On 19 Mar 2014, at 18

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

You’re right but we’ve never received a report of any charset interop. issues. Probably such a scenario has never been encountered by customers. On 21 Mar 2014, at 05:54, Xueming Shen xueming.s...@oracle.com wrote: Obj.java:#482 It appears sun.misc.BASE64Decoder.decodeBuffer(String) uses

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

and I'll file a CCC to track this. Yes. I think that’s the right approach as the compatibility risk is low. Mandy On 3/21/2014 2:23 AM, Vincent Ryan wrote: You’re right but we’ve never received a report of any charset interop. issues. Probably such a scenario has never been encountered

Re: RFR - 8042857: 14 stuck threads waiting for notification on LDAPRequest

Fix looks fine Rob. Thanks. On 16 May 2014, at 17:00, Rob McKenna rob.mcke...@oracle.com wrote: Hi folks, A simple fix to eliminate a possible infinite loop when an Ldap Connection cannot contact the server. http://cr.openjdk.java.net/~robm/8042857/webrev.01/ -Rob

Re: RFR - 8041451: com.sun.jndi.ldap.Connection:ReadTimeout should abandon ldap request

That fix looks fine. Thanks. On 23 May 2014, at 18:08, Rob McKenna rob.mcke...@oracle.com wrote: Hi folks, Very simple fix to ensure that a slow server isn't left waiting around for a request we have already given up on. http://cr.openjdk.java.net/~robm/8041451/webrev.01/ -Rob

Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation

Thanks Jeremy. I believe you have JDK 9 Author status so can sponsor your fix if you wish. On 27 May 2014, at 21:09, Jeremy Manson jeremyman...@google.com wrote: Just like the title says - every time you generate a new private key, you leak a little memory. Webrev here:

Re: RFR: 8044059: Memory Leak in Elliptic Curve Private Key Generation

On Wed, May 28, 2014 at 8:52 AM, Vincent Ryan vincent.x.r...@oracle.com wrote: I’ll begin reviewing your changeset and get back to you. Thanks. On 28 May 2014, at 16:28, Jeremy Manson jeremyman...@google.com wrote: Ah, okay. Thanks, Iris. I should already know known that - Martin

Re: RFR JDK-8047062: Improve diagnostic output in com/sun/jndi/ldap/LdapTimeoutTest.java

Looks fine Pavel. On 17 Jun 2014, at 14:06, Pavel Rappo pavel.ra...@oracle.com wrote: Hi everyone, Could you please review my change for JDK-8047062? http://cr.openjdk.java.net/~prappo/8047062/webrev.00/ Thanks -Pavel

[9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded

Please review the following simple changeset to identify the offending JAR file following a signature verification error. Previously, only the offending entry in the JAR was identified. This helps during troubleshooting when several JAR files being processed. The request was originally

Re: [9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded

I shortened the output to display only the JAR filename to avoid leaking filesystem information. I’ve updated the webrev in-place. Thanks. On 19 Jun 2014, at 17:59, Vincent Ryan vincent.x.r...@oracle.com wrote: Please review the following simple changeset to identify the offending JAR

Re: [9] request for review 8047353: Improve error message when a JAR with invalid signatures is loaded

Hello Aaron, I considered using your testcase that manually generates the necessary malformed JAR but as there was a suitable signed JAR already in the test suite I decided to re-use that. I think it makes sense to re-work the test as a Java program. Unfortunately I’ll be on vacation from

Re: RFR JDK-8049884: Reduce possible timing noise in com/sun/jndi/ldap/LdapTimeoutTest.java

This change looks fine Pavel and eliminates another intermittent test failure. Thanks. On 11 Jul 2014, at 14:59, Pavel Rappo pavel.ra...@oracle.com wrote: Hi everyone, Could you please review my change for JDK-8049884? http://cr.openjdk.java.net/~prappo/8049884/webrev.00/ Thanks

Re: RFR JDK-8048175: Remove redundant use of reflection on core classes from JNDI

The LDAP changes look fine to me. Thanks. On 15 Jul 2014, at 15:07, Mark Sheppard mark.shepp...@oracle.com wrote: Hi Pavel, the changes look ok I've run some relevant jck tests (naming management rmi) and the CORBA regression suite for the changeset, with no perceptible issues

Re: RFR JDK-8051991: Flatten VersionHelper hierarchies

Look fine Pavel. Thanks. On 25 Jul 2014, at 13:59, Pavel Rappo pavel.ra...@oracle.com wrote: Hi everyone, Could you please review my change for JDK-8051991? http://cr.openjdk.java.net/~prappo/8051991/webrev.00/ -Pavel

Re: RFR JDK-8054158: Fix typos in JNDI-related packages

Thanks for fixing those typso. On 1 Aug 2014, at 16:50, Pavel Rappo pavel.ra...@oracle.com wrote: Hi everyone, Could you please review my change for JDK-8054158? http://cr.openjdk.java.net/~prappo/8054158/webrev.00/ -Pavel

Re: Fake DNS query result inside a test

Are you suggesting to run a local DNS server? If so then it is easy to access that via a JNDI context. If you're proposing developing a basic JNDI service provider then that would be more effort. On 7 Nov 2012, at 01:05, Weijun Wang wrote: Hi Vinnie I want to write a regression test so

Re: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

The JAAS and JGSS changes look fine too. On 7 Oct 2013, at 09:23, Chris Hegarty wrote: Alan, I checked the httpsever and sctp changes. All look good to me. -Chris. On 10/06/2013 09:03 PM, Alan Bateman wrote: As a follow-up to Joe Darcy's rename of jdk.Supported to jdk.Exported,

[8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

Please review this fix to correct the JDK8 build Configure script. It reverts a recent change to common/autoconf/basics.m4 that was causing a build failure on Solaris. Bug: https://bugs.openjdk.java.net/browse/JDK-8027567 Webrev: http://cr.openjdk.java.net/~vinnie/8027567/

Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

resolve the problem in tl, and sync back into master, but Erik should ensure that the original issue is still fixed, 8026528: [build] configure does not recognize newer make in cygwin -Chris. [1] http://hg.openjdk.java.net/jdk8/build/rev/1a853fac18ff On 30/10/2013 14:40, Vincent Ryan wrote

Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

\.\)' the same as gnu grep. In jprt it finds /usr/sfw/bin/ggrep which works better. I will see if I can figure out something that works with both. /Erik On 2013-10-30 16:28, Vincent Ryan wrote: Thanks Chris. So reverting to the previous version of builds.m4 will fix this issue on Solaris

Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

and to also submit the closed generated-configure. /Erik On 2013-10-30 17:07, Vincent Ryan wrote: Thanks Erik. We’re seeing the issue in TL so it’d be great to get this fixed today. Would you like to take ownership of this issue or shall I push your fix to TL? On 30 Oct 2013, at 16:00

Re: [8] RfR 8027567: JDK8 build failure: the correct version of GNU make is being rejected

for this. ( generated-configure.sh, I just assume is ok once common/autoconf/autogen.sh is run ). -Chris. On 30/10/2013 16:24, Vincent Ryan wrote: Sure. I’ll re-run autogen.sh and submit an updated webrev. Thanks. On 30 Oct 2013, at 16:15, Erik Joelssonerik.joels...@oracle.com wrote: I'm leaving

Re: 7056489: test/com/sun/jndi/ldap/ReadTimeoutTest.java loops or times out

Your fix looks good. On 18/06/2011 20:39, Alan Bateman wrote: I need a reviewer for a small fix to a test that I caught looping on my syst.em. The test creates a server thread that emulates a non responding LDAP server. Unfortunately the thread goes into a loop reading from the connection once

Re: 7056489: test/com/sun/jndi/ldap/ReadTimeoutTest.java loops or times out

Apologies for overlooking the core-libs audience. On 06/20/11 23:42, Joe Darcy wrote: Vincent Ryan wrote: On 06/20/11 16:08, Alan Bateman wrote: Vincent Ryan wrote: : Thanks Alan. JNDI applications are encouraged to call close() rather than rely on GC to free resources. I guess

Re: Code review request: 6961765: Double byte characters corrupted in DN for LDAP referrals

Your fix looks fine. On 03/ 6/12 08:32 AM, Weijun Wang wrote: Hi Vinnie This bug is about using UrlUtil.decode() to decode a URL that is not fully encoded, i.e. including non-ASCII characters. The webrev is at http://cr.openjdk.java.net/~weijun/6961765/webrev.00/ It simply delegates the

hg: jdk7/tl/jdk: 6872048: bad private keys are generated for 2 specific ECC curves

Changeset: dd997cc0c823 Author:vinnie Date: 2009-08-24 18:37 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd997cc0c823 6872048: bad private keys are generated for 2 specific ECC curves Reviewed-by: wetmore ! src/share/native/sun/security/ec/ec.c !

hg: jdk7/tl/jdk: 6884175: CR cleanup for 6840752: Provide out-of-the-box support for ECC algorithms

Changeset: 845fefff00a4 Author:vinnie Date: 2009-09-21 23:01 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/845fefff00a4 6884175: CR cleanup for 6840752: Provide out-of-the-box support for ECC algorithms Reviewed-by: wetmore ! make/sun/security/ec/Makefile !

hg: jdk7/tl/jdk: 6885204: JSSE should not require Kerberos to be present

Changeset: 54118c8e0ebe Author:vinnie Date: 2009-10-05 23:42 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/54118c8e0ebe 6885204: JSSE should not require Kerberos to be present Reviewed-by: wetmore, alanb !

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 561186928899 Author:vinnie Date: 2009-12-02 17:06 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/561186928899 6906510: Fix testcase for 6894643: Separate out dependency on Kerberos Reviewed-by: weijun ! test/sun/security/krb5/auto/SSL.java Changeset:

hg: jdk7/tl/jdk: 6906854: SSL/Krb5 testcase should not use a fixed port number

Changeset: bc12627832e0 Author:vinnie Date: 2009-12-03 21:30 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc12627832e0 6906854: SSL/Krb5 testcase should not use a fixed port number Reviewed-by: alanb ! test/ProblemList.txt ! test/sun/security/krb5/auto/SSL.java

hg: jdk7/tl/jdk: 6876158: Remove dependencies on Signer, Certificate, Identity, IdentityScope classes from java.security pkg

Changeset: 327adb1c2224 Author:vinnie Date: 2009-12-07 17:06 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/327adb1c2224 6876158: Remove dependencies on Signer, Certificate, Identity, IdentityScope classes from java.security pkg Reviewed-by: alanb, mullan !

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 117b245b5bb9 Author:vinnie Date: 2010-01-21 23:59 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/117b245b5bb9 6763530: Cannot decode PublicKey (Proider SunPKCS11, curve prime256v1) Reviewed-by: andrew ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java !

Re: RFR JDK-8059311: com/sun/jndi/ldap/LdapTimeoutTest.java fails with exit_code == 0

All looks good. Thanks. On 7 Nov 2014, at 12:14, Pavel Rappo pavel.ra...@oracle.com wrote: Hi everyone, Could you please review my change for JDK-8059311? http://cr.openjdk.java.net/~prappo/8059311/webrev.00/ It looks

Re: RFR: 8065238 - javax.naming.NamingException after upgrade to JDK 8

Changes look fine to me Rob. Thanks. On 5 Dec 2014, at 05:17, Rob McKenna rob.mcke...@oracle.com wrote: Just updated the test to workaround a seemingly unrelated platform specific issue. (that only manifests on older kernels) http://cr.openjdk.java.net/~robm/8065238/webrev.02/ -Rob

Re: RFR (XS) 8074761: Empty optional parameters of LDAP query are not interpreted as empty

Your fix looks good to me. Thanks for contributing the patch. On 25 Mar 2015, at 14:47, Stanislav Baiduzhyi baiduzhyi.de...@gmail.com wrote: On Tuesday 10 March 2015 17:18:06 Stanislav Baiduzhyi wrote: Hi All, Please review the patch for LdapURL. Patch fixes the parsing of query part

Re: RFR: 8132455 - com/sun/jndi/ldap/LdapTimeoutTest.java fails at handleNamingException

That looks fine for now. Thanks. > On 11 Nov 2015, at 15:11, Rob McKenna wrote: > > So unfortunately this isn't a real fix for this failing test. (intermittent, > certain platforms only) However since I have enough information to > investigate this problem separately

Re: RFR: 8129957 - Deadlock in JNDI LDAP implementation when closing the LDAP context

Your proposed fix looks fine Rob. Thanks. > On 14 Sep 2015, at 16:25, Rob McKenna wrote: > > Hi folks, > > So on further investigation it looks like we could get away with reducing the > amount of locking in LdapClient. Here is a proposed fix followed by a >

Re: RFR : 8139965:Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

IIRC pausing the receiver was introduced to prevent an LDAP client (with limited memory) from being overwhelmed by server results and having no opportunity to transmit an abandon request. The 80% value was chosen to balance maximising queue capacity against the risk of an OOME. If that

Re: Process to add some default methods to javax.naming.Context?

Hello Laird, The problem of having to cast the result of Context.lookup can be solved using an existing method: InitialContext.doLookup

Re: Process to add some default methods to javax.naming.Context?

;ljnel...@gmail.com> wrote: > > On Fri, Oct 14, 2016 at 7:19 AM Vincent Ryan <vincent.x.r...@oracle.com > <mailto:vincent.x.r...@oracle.com>> wrote: > The problem of having to cast the result of Context.lookup > <http://download.java.net/java/jdk9/docs/api/javax/namin

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

> On 8 Dec 2016, at 07:22, David Holmes <david.hol...@oracle.com> wrote: > > On 8/12/2016 2:32 AM, Vincent Ryan wrote: >> A hexdump facility has been available for many, many years via an >> unsupported class: sun.misc.HexDumpEncoder. >> Although that class was

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

> On 8 Dec 2016, at 12:10, Vincent Ryan <vincent.x.r...@oracle.com> wrote: > > >> On 8 Dec 2016, at 07:22, David Holmes <david.hol...@oracle.com> wrote: >> >> On 8/12/2016 2:32 AM, Vincent Ryan wrote: >>> A hexdump facility has been available fo

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

e, I will add that. And matching one for dumpToStream ? > > -Ulf > > Am 07.12.2016 um 17:32 schrieb Vincent Ryan: >> A hexdump facility has been available for many, many years via an >> unsupported class: sun.misc.HexDumpEncoder. >> Although that class was always

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

too. > > Thanks, > Volker > > [1] http://openjdk.java.net/projects/jdk9/fc-extension-process > > On Wed, Dec 7, 2016 at 5:32 PM, Vincent Ryan <vincent.x.r...@oracle.com> > wrote: >> A hexdump facility has been available for many, many years via an >> unsup

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

sent it to the HexDump methods. Some ByteBuffers can be converted to a byte[] without the penalty of a copy operation. If performance becomes an issue then we can re-visit supporting ByteBuffer. > > Comments below. > > Paul. > >> On 7 Dec 2016, at 08:32, Vincent Ryan

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

Thanks for your review comments Alan. Responses below. > On 8 Dec 2016, at 19:44, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 07/12/2016 16:32, Vincent Ryan wrote: > >> A hexdump facility has been available for many, many years via an >> unsupported

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

Thanks to those who provided review comments. I have incorporated most of them and updated the webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.01/ The main changes are to tighten up the javadoc spec and to add three additional methods to support byte array ranges. The total number

Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

Unfortunately this feature has arrived a little too late so I’m withdrawing it from consideration for JDK 9. Thanks again to those who took time to review it. > On 10 Dec 2016, at 01:02, Vincent Ryan <vincent.x.r...@oracle.com> wrote: > > Thanks to those who provided review c

[9] RFR 8170769: Provide a simple hexdump facility for binary data

A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I’m proposing a very simple replacement in a new and supported class:

Re: [11] RFR: 8170769 Provide a simple hexdump facility for binary data

; > If the customizable dump method is both powerful and simple enough to create > 2) above, I'll be happy. Otherwise, I can live with > toHexString().replaceAll("(..)(?=.)", "$1:”). How about adding another toHexString method that takes a delimiter character? > >

Re: [11] RFR: 8170769 Provide a simple hexdump facility for binary data

can only think of >> >> 1. The existing sun.security.HexDumpEncoder format, when I want to dump a >> lot of bytes as a block >> 2. "00:11:22:33:AA:BB:CC" which fits in one line and also easy to read, when >> I want inline debugging output >> >>

Re: [11] RFR: 8170769 Provide a simple hexdump facility for binary data

> On 10 May 2018, at 01:08, Weijun Wang <weijun.w...@oracle.com> wrote: > > > >> On May 10, 2018, at 6:49 AM, Vincent Ryan <vincent.x.r...@oracle.com> wrote: >> >>> >>> - As Max observes, being able to supply the delimiters might be

Re: Charsets for hex/base64

FYI here’s the javadoc for a draft of the Hex API that Alan mentioned below: http://cr.openjdk.java.net/~vinnie/8170769/javadoc.05/api/java.base/java/util/Hex.html Thanks. > On 2 May 2018, at 10:55, Jonas Konrad wrote: > > I did not know about the old HexDumpEncoder. It extends

[11] RFR: 8170769 Provide a simple hexdump facility for binary data

Hello, Please review this proposal for a new API to conveniently generate and display binary data using hex string representation. It supports both bulk and stream operations and it can also generate the well-known hexdump format [1]. Thanks Bug:

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Responses in-line. > On 10 Dec 2018, at 21:38, Roger Riggs wrote: > > Hi Vincent, > > On 12/10/2018 03:59 PM, Vincent Ryan wrote: >> Comments in-line. >> Thanks. >> >>> On 10 Dec 2018, at 16:59, Roger Riggs >> <mailto:roger.ri...@oracle.co

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

ll those who provided review comments. > On 12 Dec 2018, at 12:32, Vincent Ryan wrote: > > Thanks for your proposal. > Comments below. > >> On 12 Dec 2018, at 02:35, Stuart Marks wrote: >> >> >> >> On 12/11/18 1:21 PM, Vincent Ryan wrote: >>>

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

example is correct, there is > no reference > to a stream, only the PrintStream::println method, which is not static. The code is just illustrative. Real values would have to be supplied for the input bytes and the chosen print method on the output stream. Typically, that print method w

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

a/util/HexFormat.html <http://cr.openjdk.java.net/~vinnie/8170769/javadoc.08/api/java.base/java/util/HexFormat.html> > On 11 Dec 2018, at 13:04, Alan Bateman wrote: > > On 08/12/2018 01:18, Vincent Ryan wrote: >> Here’s the latest version that addresses all the current open

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

> > Ho Vincent, > > On 12/11/2018 11:34 AM, Vincent Ryan wrote: >> Responses in-line. >> >>> >>>> Its really nice/necessary that examples can be copy/pasted and compile. >>>>> >>>>> >>>>> - dumpAsStream(

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

> On 11 Dec 2018, at 02:11, Stuart Marks wrote: > > On 12/7/18 10:22 AM, Vincent Ryan wrote: >>> I'm not convinced that the overloads that send output to an OutputStream >>> pull their weight. They basically wrap the OutputStream in a PrintStream, >>> which

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Thanks for your proposal. Comments below. > On 12 Dec 2018, at 02:35, Stuart Marks wrote: > > > > On 12/11/18 1:21 PM, Vincent Ryan wrote: >> My preference is for PrintStream rather than Writer, for the same reason as >> Roger: it’s more convenient >&

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

> return -1; > } > > with > > private static int hexToBinary(char ch) { > return ch <= 'f' ? staticPrecomputedArray[ch] : -1; > } > > where int[] staticPrecomputedArray is computed in a static initializer block. > > /Kasper > > On F

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

>> return -1; >> } >> >> with >> >> private static int hexToBinary(char ch) { >> return ch <= 'f' ? staticPrecomputedArray[ch] : -1; >> } >> >> where int[] staticPrecomputedArray is computed in a static initializer &

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

Thanks for your review Stuart. Comments below. > On 6 Dec 2018, at 02:18, Stuart Marks wrote: > > Hi Vinnie, > > Roger Riggs wrote: >>> The 'forEachOrdered' should not be necessary and may raise questions about >>> why. >>> if there's no good reason, use 'forEach’. > > Using

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

t.html <http://cr.openjdk.java.net/~vinnie/8170769/javadoc.07/api/java.base/java/util/HexFormat.html> CSR: https://bugs.openjdk.java.net/browse/CCC-8170769 <https://bugs.openjdk.java.net/browse/CCC-8170769> > On 7 Dec 2018, at 19:51, Vincent Ryan wrote: > > Even shorter. I’ll

Re: RFR: 8170769 Provide a simple hexdump facility for binary data

gBuilder sb = new StringBuilder(16 * 5); > sb.append(indent); > > System.out.print("byte[] bytes = {\n"); > try (ByteArrayInputStream is = new ByteArrayInputStream(b)) { > dumpAsStream(is, 16, (o, c, s, e) -> { > sb.setLength(indent.length()); >

RFR: 8170769 Provide a simple hexdump facility for binary data

Hello, Please review this proposal for a new API to conveniently generate and display binary data using hexadecimal string representation. It supports both bulk and stream operations and it can also generate the well-known hexdump format [1]. This latest revision addresses review comments