At the API level that most users work with caches, I think that's a bit too far removed. But I agree, we just need stable formats for actual release.
On 25 August 2014 14:56, Paul Benedict <[email protected]> wrote: > I wouldn't even care about a stable format. I'd take an all or nothing > approach to caches. Either you can correctly read out the objects, or throw > away your storage upon error and rebuild from scratch. > > > Cheers, > Paul > > > On Mon, Aug 25, 2014 at 2:45 PM, Gary Gregory <[email protected]> > wrote: > >> Right now I'm interested in making the objects serializable at all in the >> first place. I think we can worry about a stable format once it works ;-) >> this is WIP. >> >> Gary >> >> >> -------- Original message -------- >> From: Matt Sicker >> Date:08/25/2014 14:59 (GMT-05:00) >> To: Log4J Developers List >> Subject: On serializability >> >> I think it's great to make things Serializable as it helps move objects >> around. However, we should try to come up with some stable serialization >> formats. I don't know how many times I've had to diagnose cache-related >> problems due to serialization formats changing. Personally, I use a >> serialization pattern based on Externalizable and I always end the object >> stream with a boolean to indicate whether or not there is more data >> available (i.e., extended versions). I'm not sure how well this would work >> in a public API, but it's worked rather well in practice so far in >> preventing incompatible class errors and the like. >> >> -- >> Matt Sicker <[email protected]> >> > > -- Matt Sicker <[email protected]>
