`FieldType.CHAR` does not define `Character.class` as java type.

[ishabandi67]

Describe the bug
FieldType.CHAR does not define a javaType for itself and defaults to String.class as it's java type.

To Reproduce
Pick up any FIX message, with a CharField (for example : RootPartyIDSource)
Create a rawstring with any delimiter (example: | )
Try to parse the message using : MessageUtils.parse()
The field returned is a StringField instead of CharField.

Expected behavior
FieldType.CHAR.getJavaType() should return Character.class like other primitive types.

system information:

• OS: [Windows]
• Java version [JDK 17]
• QFJ Version [e.g. 2.3.1]

#819

[chrjohn]

Hi @ishabandi67
Thanks for the bug and the PR.
Sounds sensible, just wanted to ask for your use case on this. Is there a specific problem with this?
Thanks
Chris

[ishabandi67]

Use case:
We store the fix messages in json format for maintaining the audit history of the trade.
In some case, we want to load up the previous message in order to create a new message, for which we need to identify the java types for each tag-value.
The Message creation is successful even without this PR, however it creates StringField instead of CharField , which in turn causes the message validation to fail.

[chrjohn]

Could you post a code snippet where the validation is failing? When parsing the message and creating a FIX message it is assumed that all fields are strings anyway since that is the format in which they are sent over the wire.

[the-thing]

Hi. Cleaning up rotation.

@chrjohn

I think ishabandi67 refers to their internal code that is validating something and relies on Java type field.

quickfix.FieldType#getJavaType is not used anywhere in QuickFIX so it wouldn't hurt to make it consistent and make CHAR be a Character.class.

I think #819 is safe to merge. There are no existing tests since it is not used.

[chrjohn]

@the-thing thank you, will check during the next days.