There was an issue mentioned on the java-imageio-interest list about adding
text metadata to a JPEG image. According to the submitter:

'It still throws the following exception at the point where the saved metadata
is accessed: "JFIF APP0 must be first marker after SOI".'

(See attached testcase MetadataCreator.java...)

A follow-up on the java-imageio-interest list points out the problems with the
current spec:

I have just read the JPEG Metadata spec again, and [the submitter] is right. The
JPEG Metadata object is supposed to be able to correctly merge in a new
text node via the standard format. Unfortunately, he has found a bug (a
spec bug, no less) in the JPEG Metadata handling. The doc says:

>>setFromTree - Standard Format
>>The setFromTree operation, when given a tree in the standard format,
>>performs a reset followed by a merge of the new tree.

and

>>mergeTree - Standard Format
>>The mergeTree operation, when given a tree in the standard format, will
>>modify the native tree in the following ways:
>>...
>>Text - Each uncompressed text item is converted to a com node and
>>inserted according to the rules above for merging com nodes.

and

>>com
>>A new com node is created and inserted as follows:
>>If there already exist com nodes, the new one is inserted
>>after the last one.
>>If there are no com nodes, the new com node is inserted after the
>>app14Adobe node, if there is one.
>>If there is no app14Adobe node, the new com node is inserted at the
>>beginning of the sequence.

What all of this amounts to is that if a Text node is added it will be
placed at the front of the sequence of markers, which is illegal for
JFIF. The above spec, and the behavior, should be changed to state that
if a JFIF header is to be written, then the new com node is added after
it, not first in the sequence.