> > Interesting. > > Perhaps Marshalled object instances should also be decorated.
Yeah you'd need somewhere to start, and as I mentioned below about transparency, you'd possibly need a DEFAULT or CURRENT version, because if you're bringing in an object foreign to the VM, and you're using static analysis, you'd need to have the bytecodes available to actually compare it against, having an initial version identifier would give it a head start in terms of performance, and you don't want to brute-force hammer the network bringing in multiple dl jars, for a class that has not been seen in any version in this JVM session I think the more 'hints' you could provide to the classloader, through either compatible version ranges or soft links the better. >> >> Whichever way you want to tackle this, you'll need it to be as >> transparent a mechanism as possible so that service/bundles/clients >> that don;t specify versions work as they always have, >> > > Thanks Calum, good point, when version metadata doesn't exist, the results > from Static Analysis alone could be utilised to find API compatible import > packages. I guess classes lacking version metadata could be treated as > version 0. If someone later decides to add version metadata, perhaps after > correcting a bug, the higher versioned package would be preferred, provided > it remains API compatible and shares the same fully qualified package name. Yeah I'd say a DEFAULT (i.e. 0, although that itself may go through changes in time) and perhaps symlink-type versioning including a CURRENT. In a way, what you don't want is to break compatibility unnecessarily. Calum
