Ancient Programming

What I encounter in my software part of life is in danger of being commented upon here

Fixedformat4j 1.2.0 released

Posted by Jacob von Eyben on June 12th, 2008

This evening I released a new version of fixedformat4j containing improved error reporting when failing to parse data using the FixedFormatManager.

The lack of good error reporting was a bit of a pain. It was not easy to see where in the parsing failed and it was not possible to get a complete list of format instructions.

A new ParseException is now thrown which contains the nessesary information.

See example of the new and improved stacktrace:

com.ancientprogramming.fixedformat4j.format.ParseException: failed to parse 'barfooba' at offset 16 as java.util.Date from 'foobarfoobarfoobarfoobar'. Got format instructions from com.ancientprogramming.fixedformat4j.format.impl.MyRecord.getDateData. See details{FormatContext{offset=16, dataType=java.util.Date, formatter=com.ancientprogramming.fixedformat4j.format.impl.ByTypeFormatter}, FormatInstructions{length=8, alignment=LEFT, paddingChar=' ', fixedFormatPatternData=FixedFormatPatternData{pattern='yyyyMMdd'}, fixedFormatBooleanData=FixedFormatBooleanData{trueValue='T', falseValue='F'}, fixedFormatNumberData=FixedFormatNumberData{signing=NOSIGN, positiveSign='+', negativeSign='-'}, fixedFormatDecimalData=FixedFormatDecimalData{decimals=2, useDecimalDelimiter=false, decimalDelimiter='.'}}}
 at com.ancientprogramming.fixedformat4j.format.impl.FixedFormatManagerImpl.readDataAccordingFieldAnnotation(FixedFormatManagerImpl.java:179)
 at com.ancientprogramming.fixedformat4j.format.impl.FixedFormatManagerImpl.load(FixedFormatManagerImpl.java:70)

Feel free to download the latest version and take a look at the changelist.

6 Responses to “Fixedformat4j 1.2.0 released”

  1. Daniele Says:

    Hi. I have found and tried Fixedformat4j 1.1.1 today (no 1.2.0 on maven2 repo to date…)

    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.

  2. jeyben Says:

    @Daniele: I have requested the 1.2.0 to be uploaded to ibiblio two days ago. It usually takes a week for them to process the jira upload request.
    In the meantime you can download the jar manually and put it in your project repository.

    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.

  3. Sam Says:

    Hi Jacob,

    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

  4. jeyben Says:

    @Sam: I have corrected the bug in the 1.2.2 release. If you stumble upon other bugs or features you would like, feel free to write an issue

  5. Agusti Says:

    Hi Jeyben,

    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

  6. jeyben Says:

    @Agusti Sanchez: Thanks for your feedback!

    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.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>