Bug ID: JDK-8143863 arrays sometimes need hexadecimal dumps

Type: Enhancement
Component: core-libs
Sub-Component: java.util

Priority: P4
Status: Closed
Resolution: Duplicate

Submitted: 2015-11-24
Updated: 2017-06-01
Resolved: 2017-06-01

If an array is being used as a backing store for some other data structure, it is often more useful to get a hex dump of the array's contents than a decimal dump.

So, please add Arrays.toHexString, parallel to Arrays.toString, which will print integral values using Integer.toHexString.  The most applicable types are arrays of char, byte, short, int, and long.  The types float and double have toHexString methods, and so the array versions should be included for those also.  The type boolean (by a pun) could be rendered as 0 or 1 under the hex rubric; this is useful as a way to get a compact numeric dump of a boolean array.

For arrays of references it is possible to define a meaningful toHexString:  Boxed primitives would be displayed using hex, and embedded arrays would be recursively treated this way.  But, such a thing seems complicated and not very useful.

So it appears that we want Arrays.toHexString only for arrays of primitives.

Part of the functionality of deepToString can take an untyped object reference, classify it as a primitive array, and run the appropriate overloading on that primitive array.

It would be useful to have this dynamically typed version of Arrays.toString, in both decimal and hex forms, as an extra overloading.

Instead of returning a String, perhaps the hex conversion routine should return a freshly allocated char[]. This can easily be turned into a String using the String(char[]) constructor. But it also be appended to a StringBuilder using append(char[]). It can also be sliced into segments more easily if, as Jon Gibbons noted above, one wants to add whitespace or line breaks.
12-05-2016
Here's a version that's pretty simple, but pretty fast compared to several competing approaches: static final char[] hexChars; static { char[] ca = new char[16]; "0123456789abcdef".getChars(0, 16, ca, 0); hexChars = ca; } // convert byte array to hex string static String toHexString(byte[] array) { char[] ca = new char[array.length * 2]; int p = 0; for (byte b : array) { ca[p++] = hexChars[(b >> 4) & 0x0f]; ca[p++] = hexChars[b & 0x0f]; } return new String(ca); } Routines for other primitive types are analogous. Presumably there would also be overloads to convert array subranges. The main alternative approach I tried was to take each nibble (four bit) value and compute a char value from it using a ternary conditional and arithmetic: static final int AOFF = (int)'a' - 0x0a; ... int x = b & 0x0f; return (char)(x < 0x0a ? '0' + x : AOFF + x); But the version at the top -- the hexChars[] array lookup -- seems to be about three times faster than this alternative.
12-05-2016
Another problem comes with formatting the string: how much/often do you want whitespace, like space and newline characters inserted.
26-04-2016
A parallel request is something like: public String toHex(byte[] b) which would return arbitrary length hex strings. Long.toString(l, 16) doesn't cut it. 0x0f1bca8da512345678abcdef10368301ba5382; This code is being duplicated throughout the JDK+test, and is a common question on Stack Exchange.
26-04-2016
Annoyingly Integer/Long.toHexString lops off leading zeros, which can make it harder to eyeball differences between arrays. Perhaps a more general approach is to have a toString method that accepts a function for element to string conversion, thus enabling support for octal/hex/binary with/without leading zeros. Some boxing might be avoided if byte/short etc. values are widened to int, this would require that the IntFunction implementation have captured knowledge of the array component type to support the correct number of leading zeros.
26-11-2015