How to convert CSV row to Java object?

Discussion in 'Java' started by laredotornado, Aug 27, 2010.

  1. Hi,

    I'm using Java 1.6. Does anyone know of any library or other Java
    classes out there that would take a CSV row and convert them into a
    Java object that I've created?

    Thanks for any advice, - Dave
     
    laredotornado, Aug 27, 2010
    #1
    1. Advertising

  2. laredotornado

    markspace Guest

    On 8/27/2010 9:47 AM, laredotornado wrote:
    > Hi,
    >
    > I'm using Java 1.6. Does anyone know of any library or other Java
    > classes out there that would take a CSV row and convert them into a
    > Java object that I've created?



    http://lmgtfy.com/?q=java csv
     
    markspace, Aug 27, 2010
    #2
    1. Advertising

  3. On Aug 27, 12:40 pm, markspace <> wrote:
    > On 8/27/2010 9:47 AM, laredotornado wrote:
    >
    > > Hi,

    >
    > > I'm using Java 1.6.  Does anyone know of any library or other Java
    > > classes out there that would take a CSV row and convert them into a
    > > Java object that I've created?

    >
    > http://lmgtfy.com/?q=java csv


    Your sarcasm notwithstanding, the sourceforge Java CSV tool does not
    read a CSV row into an object -- it only parses the file, but will not
    convert each row into an object. -
     
    laredotornado, Aug 27, 2010
    #3
  4. laredotornado

    Tom Anderson Guest

    On Fri, 27 Aug 2010, laredotornado wrote:

    > I'm using Java 1.6. Does anyone know of any library or other Java
    > classes out there that would take a CSV row and convert them into a Java
    > object that I've created?


    http://flatworm.sourceforge.net/

    tom

    --
    Crazy week so far, which at one point involved spewing down the inside
    of my jeans! -- D
     
    Tom Anderson, Aug 27, 2010
    #4
  5. "Tom Anderson" <> escribió en el mensaje
    news:...
    > On Fri, 27 Aug 2010, laredotornado wrote:
    >
    >> I'm using Java 1.6. Does anyone know of any library or other Java
    >> classes out there that would take a CSV row and convert them into a Java
    >> object that I've created?

    >
    > http://flatworm.sourceforge.net/
    >
    > tom


    Perhaps you might help me.

    Since all the buzz with XML started several years ago, I've been scratching
    my head trying to understand what actual advantages it might bring when used
    to process files whose data structures are known and agreed upon in advance.
    So far, with the exception of being able to boast that your application is
    buzzword-compliant, I have found none. On the other hand, I have found
    several "cons": depending on a library that is probably less efficient than
    a traditional line oriented simple parser, overloading your project with
    dependencies plus you have to learn a new formalization for which not many
    good input editors exist (so, you must write code to turn source input into
    XML, which is alsao more complex than just concatenating and expanding
    strings).

    And in this particular case, what is the point in having to learn XML to
    write a barely readable definition instead of using Java (or any language),
    which you already know and that may achieve the same results with probably
    the same writing (and probably less thinking) effort?

    I mean, if you have a CSV file, you may just read the lines, split them,
    convert the data items that need to be converted and store the individual
    values in an object.

    Isn't all that XMLing a sort of overkill?

    Thanks.
     
    Leonardo Azpurua, Aug 27, 2010
    #5
  6. laredotornado

    Lew Guest

    laredotornado wrote:
    >>> I'm using Java 1.6. Does anyone know of any library or other Java
    >>> classes out there that would take a CSV row and convert them into a
    >>> Java object that I've created?


    markspace wrote:
    >> http://lmgtfy.com/?q=java csv


    laredotornado wrote:
    > Your sarcasm notwithstanding, the sourceforge [sic] Java CSV tool does not


    He was not being sarcastic.

    > read a CSV row into an object -- it only parses the file, but will not
    > convert each row into an object. -


    And what sort of object do you suggest it create, hm?

    And when you say "it only parses the file", into what does it parse the file,
    pray tell?

    I note that markspace's link points to many places, not just "the" SourceForge
    tool.

    Looking at OpenCSV, one of the many sites to which markspace helpfully linked,
    I see that it does indeed parse CSV input into an object, and the natural
    representation of a CSV at that.

    You should look at the information about CSV files on mindprod.com. One think
    Roedy makes clear is that CSV is not simple or precise or straightforward.

    --
    Lew
     
    Lew, Aug 27, 2010
    #6
  7. laredotornado

    Lew Guest

    Leonardo Azpurua wrote:
    > Perhaps you might help me.
    >
    > Since all the buzz with XML started several years ago, I've been scratching
    > my head trying to understand what actual advantages it might bring when used
    > to process files whose data structures are known and agreed upon in advance.
    > So far, with the exception of being able to boast that your application is
    > buzzword-compliant, I have found none. On the other hand, I have found
    > several "cons": depending on a library that is probably less efficient than
    > a traditional line oriented simple parser, overloading your project with
    > dependencies plus you have to learn a new formalization for which not many
    > good input editors exist (so, you must write code to turn source input into
    > XML, which is alsao more complex than just concatenating and expanding
    > strings).


    The advantages of XML are that it provides semantically void, human-readable,
    precise and straightforward representation of structured information. Its
    associated formalisms provide a ready-made panoply of ways to express
    specification and transformation rules. It is less susceptible to alignment
    error and such.

    > And in this particular case, what is the point in having to learn XML to
    > write a barely readable definition instead of using Java (or any language),
    > which you already know and that may achieve the same results with probably
    > the same writing (and probably less thinking) effort?


    I think that would be the wrong reason to learn XML. I would suggest rather
    learning XML to write eminently readable and unambiguous contracts and
    embodiments. Certainly context and content are more readable and more readily
    associated in an XML document than a raw CSV file.

    I never endorse doing less thinking.

    > I mean, if you have a CSV file, you may just read the lines, split them,
    > convert the data items that need to be converted and store the individual
    > values in an object.
    >
    > Isn't all that XMLing a sort of overkill?


    Depends, but often not. I mean, if you have an XML file, all you have to do
    is just plop on one of the many standard frameworks onto them, let it convert
    the items for you that need to be converted and store for you individual
    values pretty much anywhere you want. It also lets you separate concerns
    beautifully between, say, parsing and processing of content.

    --
    Lew
     
    Lew, Aug 27, 2010
    #7
  8. laredotornado

    Stefan Ram Guest

    "Leonardo Azpurua" <> writes:
    >I mean, if you have a CSV file, you may just read the lines, split them,
    >convert the data items that need to be converted and store the individual
    >values in an object.


    I can give the specification of XML:

    http://www.w3.org/TR/xml11/

    So, if anyone now would give me the specification of CSV,
    we can go on and compare the two.

    Otherwise, one can state than an advantage of XML is that
    it is specified.
     
    Stefan Ram, Aug 27, 2010
    #8
  9. laredotornado

    markspace Guest

    On 8/27/2010 1:44 PM, laredotornado wrote:

    >>
    >> http://lmgtfy.com/?q=java csv

    >
    > Your sarcasm notwithstanding, the sourceforge Java CSV tool does not
    > read a CSV row into an object -- it only parses the file, but will not
    > convert each row into an object. -



    Sarcasm or no, I feel you've been remiss not to detail the sort of
    object you require. There's a rather broad range of possibilities for
    constructing Java objects, really too many possibilities for us to guess
    what it is you want.

    Out of that list I gave you, do you see anything that looks like it
    might be useful, even partially? What about such libraries,
    specifically, do you find wanting?
     
    markspace, Aug 28, 2010
    #9
  10. laredotornado

    Jim Janney Guest

    "Leonardo Azpurua" <> writes:

    > "Tom Anderson" <> escribió en el mensaje
    > news:...
    >> On Fri, 27 Aug 2010, laredotornado wrote:
    >>
    >>> I'm using Java 1.6. Does anyone know of any library or other Java
    >>> classes out there that would take a CSV row and convert them into a Java
    >>> object that I've created?

    >>
    >> http://flatworm.sourceforge.net/
    >>
    >> tom

    >
    > Perhaps you might help me.
    >
    > Since all the buzz with XML started several years ago, I've been scratching
    > my head trying to understand what actual advantages it might bring when used
    > to process files whose data structures are known and agreed upon in advance.
    > So far, with the exception of being able to boast that your application is
    > buzzword-compliant, I have found none. On the other hand, I have found
    > several "cons": depending on a library that is probably less efficient than
    > a traditional line oriented simple parser, overloading your project with
    > dependencies plus you have to learn a new formalization for which not many
    > good input editors exist (so, you must write code to turn source input into
    > XML, which is alsao more complex than just concatenating and expanding
    > strings).
    >
    > And in this particular case, what is the point in having to learn XML to
    > write a barely readable definition instead of using Java (or any language),
    > which you already know and that may achieve the same results with probably
    > the same writing (and probably less thinking) effort?
    >
    > I mean, if you have a CSV file, you may just read the lines, split them,
    > convert the data items that need to be converted and store the individual
    > values in an object.
    >
    > Isn't all that XMLing a sort of overkill?
    >
    > Thanks.


    I see two main advantages to XML. First, it allows you to structure
    data hierarchically, unlike CSV or properties files which are flat.
    Second, there's a huge number of freely available Java libraries to
    handle parsing and processing XML. Write a schema and load it into a
    schema-aware editor and even editing isn't that bad.

    Yes, it's big and bloated and ugly and if I had my 'druthers I'd be
    using S-expressions instead, but storage is cheap and processors are
    fast and for me the advantages outweigh my personal preferences.

    --
    Jim Janney
     
    Jim Janney, Aug 28, 2010
    #10
  11. laredotornado

    Tom Anderson Guest

    On Fri, 27 Aug 2010, Stefan Ram wrote:

    > "Leonardo Azpurua" <> writes:
    >> I mean, if you have a CSV file, you may just read the lines, split them,
    >> convert the data items that need to be converted and store the individual
    >> values in an object.

    >
    > I can give the specification of XML:
    >
    > http://www.w3.org/TR/xml11/
    >
    > So, if anyone now would give me the specification of CSV,
    > we can go on and compare the two.


    http://www.ietf.org/rfc/rfc4180.txt

    I don't know how good compliance to this spec is, to put it mildly.

    But then, half the XML out there today uses namespaces, and there is no
    coherent spec for namespaces. Yes, there is a spec, but you can't actually
    use it in practice without violating the main XML spec.

    > Otherwise, one can state than an advantage of XML is that
    > it is specified.


    Except that nobody ever gives you an XML file. They give you a file in
    some particular application of XML - XHTML or DocBook or WSDL or whatever.
    You need a separate spec for that to be able to do anything useful with
    it. When someone gives you a CSV, you're in much the same situation.

    tom

    --
    Why did one straw break the camel's back? Here's the secret: the million
    other straws underneath it - it's all mathematics. -- Mos Def
     
    Tom Anderson, Aug 28, 2010
    #11
  12. "Tom Anderson" <> wrote in message
    news:...
    > On Fri, 27 Aug 2010, Stefan Ram wrote:
    >
    >> "Leonardo Azpurua" <> writes:
    >>> I mean, if you have a CSV file, you may just read the lines, split them,
    >>> convert the data items that need to be converted and store the
    >>> individual
    >>> values in an object.

    >>
    >> I can give the specification of XML:
    >>
    >> http://www.w3.org/TR/xml11/
    >>
    >> So, if anyone now would give me the specification of CSV,
    >> we can go on and compare the two.

    >
    > http://www.ietf.org/rfc/rfc4180.txt
    >
    > I don't know how good compliance to this spec is, to put it mildly.
    >
    > But then, half the XML out there today uses namespaces, and there is no
    > coherent spec for namespaces. Yes, there is a spec, but you can't actually
    > use it in practice without violating the main XML spec.


    Huh?
     
    Mike Schilling, Aug 28, 2010
    #12
  13. laredotornado

    Roedy Green Guest

    On Fri, 27 Aug 2010 09:47:14 -0700 (PDT), laredotornado
    <> wrote, quoted or indirectly quoted someone
    who said :

    >I'm using Java 1.6. Does anyone know of any library or other Java
    >classes out there that would take a CSV row and convert them into a
    >Java object that I've created?


    see http://mindprod.com/jgloss/csv.html
    for your options.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    You encapsulate not just to save typing, but more importantly, to make it easy and safe to change the code later, since you then need change the logic in only one place. Without it, you might fail to change the logic in all the places it occurs.
     
    Roedy Green, Aug 28, 2010
    #13
  14. laredotornado

    Arne Vajhøj Guest

    On 28-08-2010 06:12, Tom Anderson wrote:
    > On Fri, 27 Aug 2010, Stefan Ram wrote:
    >
    >> "Leonardo Azpurua" <> writes:
    >>> I mean, if you have a CSV file, you may just read the lines, split them,
    >>> convert the data items that need to be converted and store the
    >>> individual
    >>> values in an object.

    >>
    >> I can give the specification of XML:
    >>
    >> http://www.w3.org/TR/xml11/
    >>
    >> So, if anyone now would give me the specification of CSV,
    >> we can go on and compare the two.

    >
    > http://www.ietf.org/rfc/rfc4180.txt
    >
    > I don't know how good compliance to this spec is, to put it mildly.
    >
    > But then, half the XML out there today uses namespaces, and there is no
    > coherent spec for namespaces. Yes, there is a spec, but you can't
    > actually use it in practice without violating the main XML spec.


    People seems to be using name spaces in XML accepted by all
    XML parsers all over the world.

    >> Otherwise, one can state than an advantage of XML is that
    >> it is specified.

    >
    > Except that nobody ever gives you an XML file. They give you a file in
    > some particular application of XML - XHTML or DocBook or WSDL or
    > whatever. You need a separate spec for that to be able to do anything
    > useful with it. When someone gives you a CSV, you're in much the same
    > situation.


    Not a very accurate description.

    The rules for XML apply to all XML formats.

    And there are standards for describing the XML formats.

    Arne
     
    Arne Vajhøj, Aug 29, 2010
    #14
  15. laredotornado

    Arne Vajhøj Guest

    On 27-08-2010 18:38, Leonardo Azpurua wrote:
    > Since all the buzz with XML started several years ago, I've been scratching
    > my head trying to understand what actual advantages it might bring when used
    > to process files whose data structures are known and agreed upon in advance.
    > So far, with the exception of being able to boast that your application is
    > buzzword-compliant, I have found none. On the other hand, I have found
    > several "cons": depending on a library that is probably less efficient than
    > a traditional line oriented simple parser, overloading your project with
    > dependencies plus you have to learn a new formalization for which not many
    > good input editors exist (so, you must write code to turn source input into
    > XML, which is alsao more complex than just concatenating and expanding
    > strings).
    >
    > And in this particular case, what is the point in having to learn XML to
    > write a barely readable definition instead of using Java (or any language),
    > which you already know and that may achieve the same results with probably
    > the same writing (and probably less thinking) effort?
    >
    > I mean, if you have a CSV file, you may just read the lines, split them,
    > convert the data items that need to be converted and store the individual
    > values in an object.
    >
    > Isn't all that XMLing a sort of overkill?


    If you:
    - only use "rectangular" data
    - don't believe in documentation
    - don't believe in type safeness
    then I can not see any reason why not just use CSV instead of XML.

    But a lot of people have needs for data with more advanced
    structures than rows x columns, like the ability to document
    the format in schema/DTD and the ability to check both
    format and data values against the definition (checking
    data values requires schema).

    Arne
     
    Arne Vajhøj, Aug 29, 2010
    #15
  16. "Arne Vajhøj" <> wrote in message
    news:4c79c467$0$50450$...
    > On 28-08-2010 06:12, Tom Anderson wrote:


    >>
    >> Except that nobody ever gives you an XML file. They give you a file in
    >> some particular application of XML - XHTML or DocBook or WSDL or
    >> whatever. You need a separate spec for that to be able to do anything
    >> useful with it. When someone gives you a CSV, you're in much the same
    >> situation.

    >
    > Not a very accurate description.
    >
    > The rules for XML apply to all XML formats.
    >
    > And there are standards for describing the XML formats.


    That is, XML provides precise rules for meta-syntax, escaping, whitespace,
    line-termination, and character encodings, while CSV does not.
     
    Mike Schilling, Aug 29, 2010
    #16
  17. laredotornado

    Tom Anderson Guest

    On Sat, 28 Aug 2010, Mike Schilling wrote:

    > "Tom Anderson" <> wrote in message
    > news:...
    >
    >> But then, half the XML out there today uses namespaces, and there is no
    >> coherent spec for namespaces. Yes, there is a spec, but you can't
    >> actually use it in practice without violating the main XML spec.

    >
    > Huh?


    From section 5 of the namespace spec [1]:

    Note that DTD-based validation is not namespace-aware in the following
    sense: a DTD constrains the elements and attributes that may appear in a
    document by their uninterpreted names, not by (namespace name, local
    name) pairs. To validate a document that uses namespaces against a DTD,
    the same prefixes must be used in the DTD as in the instance.

    Basically, DTD doesn't know about namespaces. It works against the names
    as written in the file, not the way they're interpreted via the namespace
    mechanism. That means that this document:

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    <xhtml:html xmlns:xhtml="http://www.w3.org/1999/xhtml">
    <xhtml:head>
    <xhtml:title></xhtml:title>
    </xhtml:head>
    <xhtml:body>
    </xhtml:body>
    </xhtml:html>

    Is not valid, because of all those "xhtml:" strings.

    Basically, if you have a DTD which doesn't hardcode a namespace prefix
    (and it would be a bit self-defeating to), you can't use that document
    type with a namespace prefix. You can use it with the xmlns= prefixless
    declaration, but there's no way to mix and match elements from two
    namespaces while staying valid.

    I guess that in fact (a) most people use a single namespace for a whole
    document, often with a prefixless namespace and (b) virtually nobody uses
    DTDs, so this is not as bad as it seems (to me). But i still boggle at the
    fact that the namespace guys managed to write a spec that fails so
    completely to interoperate with the spec it's built on top of.

    tom

    [1] http://www.w3.org/TR/REC-xml-names/#ns-using

    --
    There are lousy reviews, and then there's empirical shitness. -- pikelet
     
    Tom Anderson, Aug 29, 2010
    #17
  18. "Arne Vajhøj" <> escribió en el mensaje
    news:4c79c59a$0$50441$...
    > If you:
    > - only use "rectangular" data
    > - don't believe in documentation
    > - don't believe in type safeness
    > then I can not see any reason why not just use CSV instead of XML.
    >
    > But a lot of people have needs for data with more advanced
    > structures than rows x columns, like the ability to document
    > the format in schema/DTD and the ability to check both
    > format and data values against the definition (checking
    > data values requires schema).


    Hi,

    I can't see the need for such a radical dismissal.

    I can concede that XML is very useful for many purposes, most of them
    related to the non-rectangularity of data.

    If I were to publish complex datasets that would be consumed by several
    applications, many of which I wouldn't ever just know about, I would
    probably use XML.

    But it is not the case for roughly 95% of current usages of XML. Most data
    trasfers are Point to Point, and mosty of them are based on a predefined
    schema shared by both parties. And most of them are rectangular. So, 95% of
    XML usages are overkill due to buzz.

    I believe in documentation. I just don't believe that every single piece of
    data needs to be documented.

    And I believe in type safeness, but I don't see what real advantage XML
    provides to type safeness when compared with a sound method for parsing
    delimited text files.

    Regards!
     
    Leonardo Azpurua, Aug 29, 2010
    #18
  19. "Tom Anderson" <> wrote in message
    news:...
    > On Sat, 28 Aug 2010, Mike Schilling wrote:
    >
    >> "Tom Anderson" <> wrote in message
    >> news:...
    >>
    >>> But then, half the XML out there today uses namespaces, and there is no
    >>> coherent spec for namespaces. Yes, there is a spec, but you can't
    >>> actually use it in practice without violating the main XML spec.

    >>
    >> Huh?

    >
    > From section 5 of the namespace spec [1]:
    >
    > Note that DTD-based validation is not namespace-aware in the following
    > sense: a DTD constrains the elements and attributes that may appear in a
    > document by their uninterpreted names, not by (namespace name, local
    > name) pairs. To validate a document that uses namespaces against a DTD,
    > the same prefixes must be used in the DTD as in the instance.
    >
    > Basically, DTD doesn't know about namespaces. It works against the names
    > as written in the file, not the way they're interpreted via the namespace
    > mechanism. That means that this document:
    >
    > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    > "http://www.w3.org/TR/html4/strict.dtd">
    > <xhtml:html xmlns:xhtml="http://www.w3.org/1999/xhtml">
    > <xhtml:head>
    > <xhtml:title></xhtml:title>
    > </xhtml:head>
    > <xhtml:body>
    > </xhtml:body>
    > </xhtml:html>
    >
    > Is not valid, because of all those "xhtml:" strings.
    >
    > Basically, if you have a DTD which doesn't hardcode a namespace prefix
    > (and it would be a bit self-defeating to), you can't use that document
    > type with a namespace prefix. You can use it with the xmlns= prefixless
    > declaration, but there's no way to mix and match elements from two
    > namespaces while staying valid.
    >
    > I guess that in fact (a) most people use a single namespace for a whole
    > document, often with a prefixless namespace


    This often isn't possible, e.g. with a WSDL that includes XMLSchema
    definitions, or any SOAP document, since they contain both SOAP and
    user-defined elements.

    > and (b) virtually nobody uses DTDs, so this is not as bad as it seems (to
    > me).


    That's the big one. DTDs were a botch; otherwise, XML would have been rev'ed
    to include namespace-aware DTDs.

    > But i still boggle at the fact that the namespace guys managed to write a
    > spec that fails so completely to interoperate with the spec it's built on
    > top of.


    But "fails to interoperate with an optional, obsolescent feature" isn't the
    same as "can't actually use it in practice without violating the main XML
    spec.".
     
    Mike Schilling, Aug 29, 2010
    #19
  20. In article <i5e4br$43m$-september.org>,
    "Leonardo Azpurua" <> wrote:

    > "Arne Vajhøj" <> escribió en el mensaje
    > news:4c79c59a$0$50441$...
    > > If you:
    > > - only use "rectangular" data
    > > - don't believe in documentation
    > > - don't believe in type safeness
    > > then I can not see any reason why not just use CSV instead of XML.
    > >
    > > But a lot of people have needs for data with more advanced
    > > structures than rows x columns, like the ability to document
    > > the format in schema/DTD and the ability to check both
    > > format and data values against the definition (checking
    > > data values requires schema).

    >
    > I can't see the need for such a radical dismissal.
    >
    > I can concede that XML is very useful for many purposes, most of them
    > related to the non-rectangularity of data.
    >
    > If I were to publish complex datasets that would be consumed by
    > several applications, many of which I wouldn't ever just know about,
    > I would probably use XML.
    >
    > But it is not the case for roughly 95% of current usages of XML. Most
    > data trasfers are Point to Point, and mosty of them are based on a
    > predefined schema shared by both parties. And most of them are
    > rectangular. So, 95% of XML usages are overkill due to buzz.
    >
    > I believe in documentation. I just don't believe that every single
    > piece of data needs to be documented.
    >
    > And I believe in type safeness, but I don't see what real advantage
    > XML provides to type safeness when compared with a sound method for
    > parsing delimited text files.


    I confess I don't _always_ validate, but it's one more line of defense
    against junk sneaking into my database; and I can rely on someone else's
    "sound method for parsing."

    <http://onjava.com/pub/a/onjava/2004/09/15/schema-validation.html>

    Yes, I use CSV, too. :)

    <http://www.h2database.com/javadoc/org/h2/tools/Csv.html>

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
     
    John B. Matthews, Aug 29, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michal Mikolajczyk
    Replies:
    0
    Views:
    696
    Michal Mikolajczyk
    Feb 13, 2004
  2. Skip Montanaro
    Replies:
    0
    Views:
    768
    Skip Montanaro
    Feb 13, 2004
  3. Replies:
    4
    Views:
    9,663
  4. D
    Replies:
    0
    Views:
    257
  5. Replies:
    1
    Views:
    150
Loading...

Share This Page