I have created issues on the two (for me:-) most interesting suggestions you came with. You can see and follow them here as well as you can create new issues.

Congratulations for this API. It’s really useful.

I have some suggestions.

ParseException

The message contains lots of information, but I wished to choose what information to show the user and the format of the message.

So it would be a great idea if you kept the data that you pass into the constructor as class fields and make them available by getter methods. So that client code would be able to catch the ParseException, retrieve the pieces of information it has interest in and build a custom error message in a convenient way.

Unparsed Chunks

Sometimes some columns should be handled like constants; ie, they are skipped at parsing time and formatted with a constant value at serializing time. It could be nice to be able to mark an attribute as “skippable” at parsing time.

Order instead of Offset

For programming convenience it would be handy sometimes to be able to define the attributes by order instead of offset. Offset-defined and order-defined attributs should not be mixed together in the same class, so the Record annotation should include a flag to tell whether offset or order is going to be used in the record definition.

Variable length / trailing columns

Smetimes the last column is optional or of variable length. From the previous comment I infer the API already handles this feature. I’ll recheck.

Strict/Loose validation

The Record annotation could include a flag to tell how strict validation should be; for example fail if actual record length does not exactly match the expected record length or try to parse as fields as possible.

Congratutalions, again, for your work.

Best Regards,

Agusti Sanchez

We are quite happy with fixed formatter except for this bug.

In our flat file , the last column’s length is 30 (and offset is 120)
but the length of the values passed is sometimes less than 30.

In this case, the parser ignores the last column and shows the value as ‘null’.

We tried paddingChar=’ ‘ to pad with spaces , but it didn’t help.

Is it a bug /limitation in present release ?

-Sam

About your custom formatter request it is already possible. I just haven’t made thorough documentation on this topic yet.

But what you have to do is implement the FixedFormatter interface (you could extend the StringFormatter and override the asString asObject methods with your validation code). Each formatter will have all the annotated data available through a FormatInstructions object.

The current StringFormatter implementation looks like this and you can access the pattern through the FormatInstructions object:

public String asString(String string, FormatInstructions instructions) {
  String result = null;
  if (string != null) {
    result = string;
  }
  return result;
}

You can use your custom formatter by adding it to the Field annotation like this:

@Field(offset = 50, length = 10, align = Align.RIGHT, paddingChar = '0', formatter = CustomFormatter.class)

I hope that helped you.

Your validation idea is good. I will find a way to implement it in the 1.3.0 release. Feel free to send me your implementation thoughts.

I really like the api and I would like to integrate in the simple mechanism it provides to read field, also my custom validation.

To say: I would like to have a string validator that check that the strings does not contains character like points and such. Or, that a Date is valid and a day 99 is not accepted (while JDK DateFormatter accept it and just updates the month).

I would Like to write my custom annotation, or use FixedFormatPattern that could accept a regex and validate it in the StringFormatter implementation.

What I am asking are not new features but if there is a way to add a custom Formatter. Here we have tried to find some entry point without any success. You have any advice?

Thanks and congratulation for nice work.