Top 31 Java Bean Utils Interview Questions You Must Prepare 19.Mar.2024

Trformer that outputs a property value.

BeanUtilsBean implementation that creates a ConvertUtilsBean2 and delegates conversion to ConvertUtilsBean.convert(Object, Class).

If your code is directly calling conversion-related methods on ConvertUtils/ConvertUtilsBean to do data conversion, then you can simply change to using LocaleBeanUtils/LocaleBeanUtilsBean/LocaleConvertUtils/LocaleConvertUtilsBean instead. The Locale-aware classes will automatically detect the locale of the host machine and set up appropriate converters for that locale. Alternatively you can explicitly create LocaleConvertUtilsBean instances providing a particular locale.

If your code is calling the property-related methods on BeanUtils/BeanUtilsBean methods, and you want the automatic type conversion facilities used to be locale-aware then you might want to look at using the equivalent methods on the LocaleBeanUtils or LocaleBeanUtilsBean classes. However because the property-related methods on these classes are not used nearly as often as the property methods on the standard (non-locale-aware) classes, they may not be as well debugged and some features may be missing.

A safer alternative to either of the above is to register custom locale-aware converters with ConvertUtils or ConvertUtilsBean:

  LongLocaleConverter  longLocaleConverter = new LongLocaleConverter(Locale.GERMAN);
  ConvertUtils.register(longLocaleConverter, Long.class);
  // now any call to any method on the BeanUtils or ConvertUtils classes which involves 
  // converting a string to a Long object will use a LongLocaleConverter which is customised 
  // to handle the German locale.

Of course the above will modify the default behaviour across the entire current application (or the current webapp if the code is running in a container environment; see the javadoc for method BeanUtils.getInstance for more information).

If you do not like the idea of changing the ConvertUtils/BeanUtils behaviour so widely, then of course you can always create a BeanUtilsBean instance and customise only the behaviour of that instance:

  ConvertUtilsBean convertUtilsBean = new ConvertUtilsBean();
  // here, customise the convertUtilsBean as required by registering custom converters
  PropertyUtilsBean propertyUtilsBean = new propertyUtilsBean();
  BeanUtilsBean beanUtilsBean = new BeanUtilsBean(convertUtilsBean, propertyUtilsBean);
  // now methods on the beanUtilsBean object will use the custom converters registered
  // on the associated ConvertUtilsBean instance.

A DynaBean is a Java object that supports properties whose names and data types, as well as values, may be dynamically modified.

BeanComparator relies on an internal Comparator to perform the actual comparisions. By default, org.apache.commons.collections.comparators.ComparableComparator is used which imposes a natural order. If you want to change the order, then a custom Comparator should be created and passed into the appropriate constructor.

For example:

     import org.apache.commons.collections.comparators.ComparableComparator;
     import org.apache.commons.collections.comparators.ReverseComparator;
     import org.apache.commons.beanutils.BeanComparator;
     ...
     BeanComparator reversedNaturalOrderBeanComparator
         = new BeanComparator("propertyName", new ReverseComparator(new ComparableComparator()));
     Collections.sort(myList, reversedNaturalOrderBeanComparator);

Simply because different regions of the world use different date layouts. There isn't any date format that is a reasonable built-in default.

  • USA: mm-dd-yyyy, mm/dd/yyyy
  • Europe/Pacific: dd-mm-yyyy
  • Other popular formats: yyyy-mm-dd, yyyymmdd

If you want BeanUtils to do implicit String->Date conversions for you, then you just need to register a suitable converter for the date formats you expect to encounter in your input.

Minimal implementation of the DynaBean interface.

Definition of an interface for components that can perform introspection on bean classes.

Say you have a map which contains a nested map ala: nestedmap.put ("key2", "somevalue"); map.put ("key1", nestedmap);

If you use the following syntax: String val = PropertyUtils.getProperty(bean, "map(key1)(key2)");

It will actually return "map(key1)", which will be a Map, not a String.

BeanUtils uses '.' as a property separator, and the second property should actually used mapped syntax, since it is directly accessing a map now, thus the correct usage should be: String val = PropertyUtils.getProperty(bean, "map(key1).key2");

Yes, we know. It says 1.@So does release 1.6.1.

Now the build system has moved to Maven that won't happen again.

JavaBean property population methods.

A DynaClass is a simulation of the functionality of java.lang.Class for classes implementing the DynaBean interface.

Oracle's JDBC driver is broken. When a query is run against a table containing a Timestamp column, the result set's metadata reports the column type (correctly) as javax.sql.Timestamp. And therefore the DynaClass object created to represent the query has a field of type javax.sql.Timestamp to store the data for that column in. However calling resultset.getObject on that column returns an object of type javax.sql.Date(!), which then of course cannot be assigned to the corresponding field on a DynaBean object with that DynaClass.

This has been reported with Oracle10g, driver ojdbc14 version 10.1.0.4.

Possible solutions (untested) are:

  • subclass RowSetDynaClass and override the copy method to fudge the conversion.
  • subclass BasicDynaBean and override the set method to handle the problem, then subclass RowSetDynaClass and override createDynaBean to return instances of your custom bean that handles broken Oracle resultsets.

Implementation of DynaBean that wraps a standard JavaBean instance, so that DynaBean APIs can be used to access its properties, though this implementation allows type conversion to occur when properties are set.

Minimal implementation of the DynaClass interface.

Predicate that evaluates a property value against a specified value.

A base class for decorators providing Map behavior on DynaBe.

A context interface used during introspection for querying and setting property descriptors.

Utility reflection methods focussed on constructors, modelled after MethodUtils.

A specialized extension to DynaClass that allows properties to be added or removed dynamically.

Predicate implementation that applies the given Predicate to the result of calling the given property getter.

General purpose data type converter that can be registered and used within the BeanUtils package to manage the conversion of objects from one type to another.

Utility methods for populating JavaBe properties via reflection.

Sorry, but ConvertUtils isn't really designed to do that. It is fundamentally about mapping strings (from xml input or web forms, etc) to objects.

The standard converter to the String type simply calls toString on its input object, so you can customise the output for objects of any particular class by modifying the toString method of that class.

Or you could replace the converter for target type String.class with a custom converter which inspects the type of the object and does a big switch statement. Or maybe even look up a mapping table of subconverter objects based on the type of the object being converted.

But in general if you need to do this, then ConvertUtils is probably the wrong tool for your job. You might like to look at morph.sourceforge.net, google for alternatives or craft your own solution.

If you don't like the default way beanutils converts strings to various datatypes, then simply register a custom converter.

So for example if you would like whitespace to be ignored when converting strings to numeric values, then create your own converter classes and register them with ConvertUtils for the datatypes you want to be affected. Note that in this case it would be easier to write a generic "filter" class that wraps the existing converters rather than create new converters classes:

  private static class WhiteSpaceConverterFilter implements Converter {
    Converter delegate;
    public WhiteSpaceConverterFilter(Converter delegate) {
      this.delegate = delegate;
    }

    public Object convert(Class clazz, Object value) {
      if (value instanceof String) {
        return delegate.convert(clazz, value.toString().trim());
      } else {
        return delegate.convert(clazz, value);
      }
    }
  }

  ConvertUtils.register(new WhiteSpaceConverterFilter(new IntegerConverter()), Integer.TYPE);

  ConvertUtils.register(new WhiteSpaceConverterFilter(new IntegerConverter(), Integer.class);

  ConvertUtils.register(new WhiteSpaceConverterFilter(new LongConverter()), Long.TYPE);

  ConvertUtils.register(new WhiteSpaceConverterFilter(new LongConverter()), Long.class);

  ....

An instance of this class represents a value that is provided per (thread) context classloader.

This comparator compares two be by the specified bean property.

Map entry used by BeanMap.

An implementation of Map for JavaBe which uses introspection to get and put properties in the bean.

The BeanUtils package relies on introspection rather than reflection. This me that it will find only JavaBean compliant properties.

There are some subtleties of this specification that can catch out the unwary:

  • A property can have only one set and one get method. Overloading is not allowed.
  • The java.be.Introspector searches widely for a custom BeanInfo class. If your class has the same name as another with a custom BeanInfo (typically a java API class) then the Introspector may use that instead of creating via reflection based on your class. If this happens, the only solution is to create your own BeanInfo.