On Sat, Aug 3, 2013 at 1:31 PM, James Carman <ja...@carmanconsulting.com>wrote:
> +1. We need to eat our own dog food when it makes sense.
Would this be the proper way to do things with [convert]?
import org.apache.commons.convert.ConversionException;
import org.apache.commons.convert.Converters;
public class CSVRecordConverter {
public CSVRecordConverter(CSVRecord record) {
super();
this.record = record;
}
private final CSVRecord record;
public boolean getBoolean(String name) throws ClassNotFoundException,
ConversionException {
return Converters.getConverter(String.class,
Boolean.class).convert(record.get(name)).booleanValue();
}
}
ClassNotFoundException seems really out of place here. I read "If no
matching Converter is found, the method throws ClassNotFoundException."
It seems to me that a ConversionException would be better.
?
Gary
> Our package
> rename approach helps solve the "jar hell" issue, so adding dependencies
> shouldn't be so frowned upon. Obviously if it's one little helper method
> here and there we can copy the code if folks are really that averse to
> dependencies.
>
>
> On Saturday, August 3, 2013, Paul Benedict wrote:
>
> > If Convert and BeanUtils do the same thing, I think Commons needs to
> figure
> > out how to solve this dilemma because duplicated functionality is usually
> > frowned upon here. For example, when Commons Lang began doing math, they
> > moved that to Commons Math (and the same thing happened for BeanUtils
> from
> > Lang).
> >
> > If Convert is to be released, I think BeanUtils should get some
> refactoring
> > for a 2.0 release. They should harmonize but not duplicate functionality.
> >
> > Paul
> >
> >
> > On Sat, Aug 3, 2013 at 11:58 AM, Gary Gregory <garydgreg...@gmail.com
> <javascript:;>
> > >wrote:
> >
> > > On Sat, Aug 3, 2013 at 12:55 PM, Adrian Crum <
> > > adrian.c...@sandglass-software.com> wrote:
> > >
> > > > On 8/3/2013 9:49 AM, Gary Gregory wrote:
> > > >
> > > >> On Sat, Aug 3, 2013 at 12:10 PM, Adrian Crum <
> > > >> adrian.crum@sandglass-**software.com <
> > > adrian.c...@sandglass-software.com>>
> > > >> wrote:
> > > >>
> > > >> Inline...
> > > >>>
> > > >>>
> > > >>> On 8/3/2013 9:05 AM, Gary Gregory wrote:
> > > >>>
> > > >>> On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum <
> > > >>>> adrian.crum@sandglass-**softwa**re.com <http://software.com> <
> > > >>>> adrian.crum@sandglass-**software.com<
> > > adrian.c...@sandglass-software.com>
> > > >>>> >>
> > > >>>>
> > > >>>> wrote:
> > > >>>>
> > > >>>> Have you considered recommending Commons Convert?
> > > >>>>
> > > >>>>> No: it is unreleased. Are you willing to help polish it to 1.0?
> > > >>>>>
> > > >>>> Aside from a pending bug fix, the code is complete. The project
> has
> > > been
> > > >>> used by Apache OFBiz for years, so it is proven and stable. So, I
> > don't
> > > >>> know what additional steps are required to polish it.
> > > >>>
> > > >>
> > > >> There's no user manual or FAQ, the Javadoc is thin. How do you get
> > > >> started?
> > > >>
> > > >
> > > >
> > > > I will try to build out the docs a little more. I think I need karma
> to
> > > > edit the Convert Wiki - adrianc.
> > > >
> > >
> > > The docs should be in SVN IMO, just like most components.
> > >
> > > Gary
> > >
> > >
> > > >
> > > >
> > > >
> > > >> More below.
> > > >>
> > > >>
> > > >> Having an official release would be wonderful.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> Yes: I'd like to eat our own dog food.
> > > >>>>
> > > >>>> Gary
> > > >>>>
> > > >>>> I agree that Java data type conversion is outside the scope of
> > CSV.
> > > >>>>
> > > >>>>> What about a CSVRecord wrapper that delegates to [convert]?
> > > >>>>>
> > > >>>> What would that look like? From my experience, hard-coding
> > conversions
> > > >>> is
> > > >>> not scalable. If an application needs to convert a CSV field to a
> > > custom
> > > >>> type Foo, how will the wrapper accommodate that?
> > > >>>
> > > >>> It would not for now. This is just about primitives or basic JRE
> > types
> > > >> like
> > > >> Number and Date (Calendar).
> > > >>
> > > >> Gary
> > > >>
> > > >>
> > > >>
> > > >>>
> > > >>> Gary
> > > >>>>
> > > >>>>
> > > >>>> -Adrian
> > > >>>>
> > > >>>>>
> > > >>>>> On 8/3/2013 8:36 AM, Gary Gregory wrote:
> > > >>>>>
> > > >>>>> Hi All:
> > > >>>>>
> > > >>>>>> I recently added these CSVRecord APIs: getBoolean(String),
> > > >>>>>> getInt(String),
> > > >>>>>> getLong(String), getBigInteger(String).
> > > >>>>>>
> > > >>>>>> Some people are OK with this, some consider this out of scope,
> > some
> > > >>>>>> consider it not necessary for 1.0, some -1, some are worried
> about
> > > >>>>>> feature
> > > >>>>>> creep (default values, Calendar, Date, List, and so on), some
> > think
> > > >>>>>> the
> > > >>>>>> Javadoc should be clearer.
> > > >>>>>>
> > > >>>>>> At the very least I think we should document how to --
> > Cheers,
> > Paul
> >
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
