Morph was inspired in part by the BeanUtils framework, so they offer similar functionality. One of Morph's goals is to provide all the functionality in the BeanUtils framework (and some nice extras), but in a much more flexible and configurable way than the BeanUtils framework.
Morph's Converter interface is nearly identitcal to the Converter interface in BeanUtils. The major difference is in how you combine multiple converters in the two frameworks.
BeanUtils takes a registry approach with its ConvertUtilsBean. This bean gives centralized control over which converters are used to convert objects to which destination classes. It requires you to explicitly register each destination class a Converter is capable of converting to. So to use a Converter, you must explicitly know which classes it can convert. Also, this approach lets you do undesireable things like register the LongConverter as the converter that knows how to convert a java.util.Date into a java.lang.Long. In fact, the BeanUtils LongConverter can't handle this conversion, so you're in store for a runtime error. (Morph's LongConverter does handle this conversion if you like, although not by default).
Morph does away with the central registry concept and instead has converters determine themselves which objects they are willing to convert via the getSourceClasses and getDestionationClasses methods. This allows you to specify multiple converters for a given destination class, each of which knows how to convert different source objects to the destination class. If you do want to combine multiple converters together (a common requirement), you can use the DelegatingConverter.
BeanUtils offers one fixed language you can use to access arbitrary properties of an object. Morph instead provides the SimpleLanguage that can recognize several familiar syntactic forms (e.g. JSTL EL, BeanUtils/Struts, Spring). Morph also allows you to define a new Language if you like (just implement the simple Language interface).
BeanUtils supports only Maps, DynaBeans, and Objects -- no more, no less. Morph allows you to expand any language to read other types of objects if needed. All you need to do is implement a BeanReflector.
Finally, The BeanUtils' syntax makes a distinction between POJOs (plain old java objects) and Maps. In our opinion, the choice of a Map vs. a POJO for a particular object is an implementation decision that should be easily changeable without requiring rework of code accessing the object. We feel that this is one of the primary benefits of using a library such as BeanUtils or Morph -- the ability to treat all 'bean-like' objects the same, whether they be Maps, Objects, DynaBeans, or YourDomainObjects. Thus, we feel this distinction is a weakness of BeanUtils' syntax (and also a disadvantage for Spring, but not for JEXL or the JSTL EL).