Lorentz 2.0 Released: A Generic Object Conversion Framework

Discussions

News: Lorentz 2.0 Released: A Generic Object Conversion Framework

  1. Lorentz 2.0, a generic object-to-object conversion framework, has been released. It provides an API to convert Java objects of one type into objects of another type. It is developed to replace all existing conversion frameworks: JavaBeans PropertyEditor, Jakarta Commons-Convert, and Jakarta Commons-BeanUtils converters, and provide a universal way to perform object conversions.

    Feature list:
    • Extensible - can be used to convert everything:
      • Currency/unit conversion
      • Bean conversion
    • Many default string-related converter implementations
    • Smart conversion engine - can perform complex conversions by combining multiple small converters intelligently. (e.g. 'A->C' is translated into 'A->B->C' automatically if required.)
    Do you think Lorentz will succeed in providing a 'universal' way to convert objects? What would it (or any other such framework) need to achieve critical mass?

    Threaded Messages (20)

  2. Well I don't know if Lorentz will succeed or not, but there are some features missing from it and its competitors that I would like to see:

    1) Localization support: Converter should allow a locale parameter, so that converters for "1,234.56" and "1 234,56" function correctly.

    2) Conversion parameters: Some conversions require additional parameters beside the raw objects themselves. Dates in particular are an issue. There needs to be a mechanism to support conversions for both "17-4-2004" and "17/4/2004" date values.

    3) The whole thing needs to be thread safe (Lorentz appears to mean this qualification, but PropertyEditors do not).

    There is definitely a need for something like this though. I see a lot of "reinventing the wheel" with String conversions, especially in web frameworks and xml-to-object binding tools.
  3. 1) Localization support: Converter should allow a locale parameter, so that converters for "1,234.56" and "1 234,56" function correctly.

    2) Conversion parameters: Some conversions require additional parameters beside the raw objects themselves. Dates in particular are an issue. There needs to be a mechanism to support conversions for both "17-4-2004" and "17/4/2004" date values.

    You're right. Lorentz lacks support for localization and various ways to represent the same data. I alreay know this issue, but I couldn't find any clear and easy way to provide the mechanism yet. Any ideas will be appreciated.
    3) The whole thing needs to be thread safe (Lorentz appears to mean this qualification, but PropertyEditors do not).

    Lorentz conversion engine itself and default converter implementations are thread safe. As for custom converters, it's up to implementors.

    Thank you for your interest on Lorentz!
    Trustin
  4. Localization aspects[ Go to top ]

    I would suggest that for extensibility, the easiest thing to do would be to extend the Converter class:

    Object convert(Object object)
        throws Exception {
        return convert(object, ConverterContext.DEFAULT);
    }
    Object convert(Object object, ConverterContext context)
        throws Exception {
    }

    The definition of ConverterContext would be similar to
    something like this:

    public class ConverterContext {
        static final DEFAULT = new ConverterContext() {
             // override setter methods here so that this
             // instance is read only
        }

        public ConverterContext();

        public Locale getLocale();
        public void setLocale(Locale locale);

        public void setAttribute(String key, Object value);
        public Object getAttribute(String key);
        
        public Map getAttributes();
    }


    In this way, any converter can be given any attributes it desires, along with the Locale which is a standard attribute, so it should have an explicit bean property. It's not necessarily typesafe, but it is flexible and
    extensible.


    ConverterContext context = new ConverterContext();
    context.setLocale(Locale.getDefault());
    context.setAttribute(StringToDateConverter.FORMAT_TYPE,
                         new Integer(DateFormat.SHORT));

    Date date = converter.convert(theString, context);
  5. Localization aspects[ Go to top ]

    Thank you, Matthew, for your detailed guideline for localization. I'll release Lorentz 2.1 as soon as I resolve most issues all you guys raised here.

    Thank you all!
  6. Lorentz 2.0, a generic object-to-object conversion framework, has been released. It provides an API to convert Java objects of one type into objects of another type.

    I just want to say that from this description you can't tell what this does. It sounds like you write any program with it ;-)
  7. Lorentz 2.0, a generic object-to-object conversion framework, has been released. It provides an API to convert Java objects of one type into objects of another type.
    I just want to say that from this description you can't tell what this does. It sounds like you write any program with it ;-)

    Well, I guess I described what it does correctly. What new description would you suggest?

    Trustin
  8. It's called a program[ Go to top ]

    The description might be correct, but it is not quite informative. It might be quite obvious to you who have felt this need in your work domain, but to me, coming as an outsider, it is not quite clear just what problem this tool solves. Maybe you could put some small examples right on the home page that illustrate why using the tool is a better way to convert than the traditional way.
  9. It's called a program[ Go to top ]

    The description might be correct, but it is not quite informative. It might be quite obvious to you who have felt this need in your work domain, but to me, coming as an outsider, it is not quite clear just what problem this tool solves. Maybe you could put some small examples right on the home page that illustrate why using the tool is a better way to convert than the traditional way.

    You're right. I had to specify some use cases of this little framework.

    When you're enough with traditional/manual conversion, that's OK. But consider when massive or automatic conversion is required (e.g. IoC containers, visual bean editors, complex currency/unit converter, bean-to-bean mapper, ...). It becomes so inconvenient when you do that all manually. That's why this framework is useful in some situation.

    Trustin
  10. I thought that the name was brilliant, considering the lorentz transformations help brigde the gap between electromagnetism and newtonian physics... How else would you know what your beans look like when they reach speed of light?

    :-)
  11. I thought that the name was brilliant, considering the lorentz transformations help brigde the gap between electromagnetism and newtonian physics... How else would you know what your beans look like when they reach speed of light?:-)

    Yes, I named it after an hour of search for keyword 'transform' and thought Lorentz was the best one. Good to see another person who's with me. :)

    If the bean reaches to the speed of light, well... Wouldn't it be a super bean which requires no transformation? :)
  12. scripting support[ Go to top ]

    Trustin - good luck with your project

    have you thought about scripting support ?
    would be nice to have groovy/other support to
    implement custom convertors - might address
    the i18n issue raised earlier..

    spring integration would also be nice

    just my 2c
  13. scripting support[ Go to top ]

    Trustin - good luck with your projecthave you thought about scripting support ?would be nice to have groovy/other support toimplement custom convertors - might addressthe i18n issue raised earlier..spring integration would also be nicejust my 2c

    Great ideas! I'll try to find out the best way to implement these ideas. :)

    Thanks,
    Trustin
  14. scripting support[ Go to top ]

    Trustin - good luck with your projecthave you thought about scripting support ?would be nice to have groovy/other support toimplement custom convertors - might addressthe i18n issue raised earlier..spring integration would also be nicejust my 2c

    I am so with you dude! And while he's at it, we could also throw in support for annotations! Imagine if we could define the conversion rules as aspects containing code written in any scripting language mentioned in JSR 223 (Javascript, PHP, Groovy)! We could use Spring's transaction support to allow for all-or-nothing, distributed conversions!
    The whole package would probably amount to some 30 MB, about the size of one of the world's most successful games ever, quake I. No doubt that's a good sign!
  15. Lorentz looks like a useful tool that is worth checking out.

    If you want a Java Bean to Java Bean mapper with conversion functionality please check out dozer.

    Dozer supports simple property mapping, complex type mapping, bi-directional mapping, implicit-explicit mapping, as well as recursive mapping. This includes mapping collection attributes that also need mapping at the element level.

    The mapper is used any time you need to take one type of Java Bean and map it to another type of Java Bean.
  16. Lorentz looks like a useful tool that is worth checking out.If you want a Java Bean to Java Bean mapper with conversion functionality please check out dozer.

    Hi Franz,

    Thank you for your interest first of all. I knew there is Dozer from TSS.com recently. Dozer was also a very interesting project which shares some concerns with Lorentz. You can think Lorentz as a generalization of Dozer and other conversion libraries. I even thought that Dozer could be implemented on top of Lorentz. WDYT?

    Trustin
  17. How long[ Go to top ]

    Before it expands into a generic XSLT based mapping tool :-)
  18. How long[ Go to top ]

    Before it expands into a generic XSLT based mapping tool :-)

    Actually, that is a part of my long-term road map. I'd like to provide some IDE-integration for users who wants to create dynamic mappings visually. But this feature overlaps with Dozer. It would be nice if all of us collaborate with this big goal. Anyone interested?

    Trustin
  19. I'll check it out...[ Go to top ]

    Always good to know there are more useful tools for doing conversions. I recently used the Morph Framework by Matt Sgarlata (http://morph.sourceforge.net/) to build data transfer objects from an O/R managed domain model. Morph saved us tons of manual coding and the converters are simple and easy to unit test. Also, it was really easy to provide converter instances their collaborating objects (like DAOs) using Spring, they're just Java objects afterall. Power through simplicity. Morph is still a beta, at 0.9.1. 1.0 release is coming soon, I'm sure. I'll have a look at Lorentz.

    Hernan Silberman
    PDI/Dreamworks
  20. What's the advantage?[ Go to top ]

    It is developed to replace all existing conversion frameworks

    What's the benefit of using Lorentz instead of, say ConvertUtils?
  21. What's the advantage?[ Go to top ]

    It is developed to replace all existing conversion frameworks
    What's the benefit of using Lorentz instead of, say ConvertUtils?

    Lorentz can convert more than Commons-BeanUtils ConvertUtils:

    * It can convert non-strings.
    * It can perform indirect conversions using backtracking algorithm.
    * It will do support locale for better and complete string conversion.

    Trustin