|General problem mapping objects to data and vice versa email@example.com (2003-02-06)|
|Re: General problem mapping objects to data and vice versa bobduff@shell01.TheWorld.com (Robert A Duff) (2003-02-11)|
|Re: General problem mapping objects to data and vice versa firstname.lastname@example.org (Peter Seibel) (2003-02-11)|
|Re: General problem mapping objects to data and vice versa email@example.com (John Stracke) (2003-03-09)|
|Re: General problem mapping objects to data and vice versa firstname.lastname@example.org (Peter Seibel) (2003-03-14)|
|From:||Peter Seibel <email@example.com>|
|Date:||11 Feb 2003 02:10:32 -0500|
|Organization:||Prodigy Internet http://www.prodigy.com|
|Posted-Date:||11 Feb 2003 02:10:32 EST|
firstname.lastname@example.org (tabbydan) writes:
> I have a general problem and am looking for tool suggestions on how
> to tackle it, and other suggestions.
> I have inherited a codebase (our application code, and supporting
> 3rd party code) that is using a "broken" data serialization
> mechanism (Java's default serialization of objects to a binary
> array). I say broken because, with the current scheme, versioning
> data is a nightmare.
> So, what I want to do is to plug in a solution whereby the objects
> in question are "automatically" serialized to something readable and
> easy to parse (thus easy to version).
> After consulting with others I have a draft solution*:
> Java code (.class or .java files) -> parsing tool (JavaCC, sableCC,
> ANTLR, ...) -> mapping logic (takes parser generated data structures
> and figures out a mapping strategy to serialize them) ->
> serialization tool (Castor, ...)
> I was wondering what tools people would recommend for this task?
For this task, the information you need (existance of fields and
methods) might be more readily at hand in the .class file; they're
pretty easy to parse. (Just remember that long and double constants
take up two slots in the constant pool and the rest is pretty straight
forward.) In theory you can use ANTLR to write a class file parser (as
it now supports binary data) but I don't know if that'll be any easier
than just writing a class file grokker by hand or using any of the
many existing bytecode manipulation libraries. This approach also has
the advantage of working on classes for which you don't have the
Return to the
Search the comp.compilers archives again.