Skip to main content

Request no.2 - working with StringBuffer

3 replies [Last post]
kirillcool
Offline
Joined: 2004-11-17
Points: 0

Original request - Allow marshaling to StringBuffer and unmarshaling from CharSequence. I am really tired of wrapping these with streams, readers and writers.
Kohsuke response - We added marshal/unmarshal that read/write from Reader/Writer. Supporting StringBuffer seems to be interesting, but doing that for CharSequence seems bit dangerous because when you pass in String, it means a system ID, not a string that looks like XML.

I think that StringBuffer should not be overlooked, although i guess you will provide the same wrapper as i made in the example code. You are right about system ID for unmarshalling, may be provide additional method, say unmarshalString()?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kohsuke
Offline
Joined: 2003-06-09
Points: 0

It occurred to me that this problem is actually a problem of JDK. The notion of a Reader from CharSequence, and the notion of a Writer to StringBuilder/StringBuffer is useful outside JAXB.

So in that sense, isn't this really a bug of JDK?

kirillcool
Offline
Joined: 2004-11-17
Points: 0

You are right. One of the few things that bug me in Java is an excessive use of decorator pattern in working with streams. Come on, create three decorators just to read contents of file one line at a time?
I'm not sure when (if at all) JDK will provide easy-to-read code for working with CharSequences as Reader/Writers, but you may bring us one step closer.
Actually, this brings me to another question - who is repsonsible for API? I mean, the function and class names, the functionality itself... If it's in your team, it will be no problem, i guess.

Kirill

kohsuke
Offline
Joined: 2003-06-09
Points: 0

You are more than welcome to file an enhancement request against JDK. They are working on Mustang nowadays, and there is a chance that your request gets through.

> Actually, this brings me to another question -
> who is repsonsible for API? I mean, the function
> and class names, the functionality itself...
> If it's in your team, it will be no problem,
> i guess.

I don't know about J2SE, but with JAXB, ultimately it's up to the EG. We can suggest changes, or for cases like this we can provide helper classes inside the RI, or maybe as a part of a sample, etc.