RFR: 8252523: Add ASN1 Formatter to work with HexPrinter [v2]

[Jamil Nimeh]

On Tue, 29 Sep 2020 19:20:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Also in that last example, it seems to suggest that the second octet string is nested within the first one since it
>> sits at a second indent layer.  They are both primitives completely covered by their two byte values so shouldn't they
>> sit at the same indentation level?  Or is the indentation not there to suggest nested substructures and is more for
>> separation between elements?  Or is this what you mean by "lost an indent"?  Also, should the end of content be at the
>> same indentation level as the initial indefinite length encoding?
>
>> Also in that last example, it seems to suggest that the second octet string is nested within the first one since it
>> sits at a second indent layer. They are both primitives completely covered by their two byte values so shouldn't they
>> sit at the same indentation level? Or is the indentation not there to suggest nested substructures and is more for
>> separation between elements? Or is this what you mean by "lost an indent"? Also, should the end of content be at the
>> same indentation level as the initial indefinite length encoding?
> 
> Yes, all of the enclosed items should be at the same indent level.  (A bug as it turns out).
> I chose to indent the END-OF-CONTENT line at the same level to terminate the list of tag-values at that level
> All of the items enclosed are at the same level.
> 
> The updated output is:
> 0000: 24 80                                           ; UNIVERSAL CONSTRUCTED OCTET STRING [INDEFINITE]
> 0002:       04 02 61 62                               ;   OCTET STRING [2] 'ab'
> 0006:                   04 02 63 64                   ;   OCTET STRING [2] 'cd'
> 000a:                               00 00             ;   END-OF-CONTENT

Regarding the end-of-content identifier, that looks good.  Thanks for fixing the indentation for the right-side ASN.1
interpretation of the bytes.  My only remaining question is whether the corresponding hex dumps on the left should
match the indentation levels as well.  I don't have a strong opinion either way on that one but if you're indenting for
each element at the same nest level it seems like that could potentially chew up a lot of horizontal space.  Was the
extra indentation for the second octet string done for readability?

-------------

PR: https://git.openjdk.java.net/jdk/pull/268