I'll get back to you on the weekend, but just to clarify, I think the
best time to collect Package API signatures is at build time, with the
build environment as it was intended by the developer. Utilising the
freshly compiled class files and third party jar files, to create dist
jar files containing the Package API signature information. I've been
referring to Package API signatures as class metadata, it doesn't have
to be shoehorned into the manifest though.
Dennis Reedy wrote:
On Nov 18, 2009, at 1105PM, Mike McGrady wrote:
There are of course limits and they come very quick to what you can do to
modify a jar file.
Very true, this goes for manifest modifications as well. Since all the 'proposed' analysis is done at build time jars can be modified with either approach. I suppose to a certain extent, its convention over configuration.
If the goal is binary compatibility, then does the existing type based lookup
and discovery mechanism that Jini provides allow evolvability of systems? If
not, where and why does it not?
Perhaps I missed this analysis on this thread, but can we break this down first
prior to jumping into implementation details?
Dennis
