On 4/1/06, Mark Wielaard <mark@xxxxxxxxx> wrote: > Maybe a better solution in that case is to invent a "magic" > serialVersionUID number that means "not-really-serializable" and tag all > classes that are not guaranteed to serialize between different > implementations/versions this way? It will be a bit more work then just > excluding whole packages of course. But at least it is more accurate and > can be used also in other situations. There are a couple of downsides to this idea. 1) With the current setup, the rule that "this class probably can't be serialized across versions" is actually somewhat enforced, in that (to a first approximation) whenever a change happens that could potentially cause incompatibility, the automatically-calculated svuid changes and deserialization fails. If the svuid were hardcoded to a constant, the deserialization behavior would be more unpredictable and more likely to do the wrong thing without actually failing. 2) The magic value would have to be in Classpath because we're not going to get Sun to change the svuids on all their Swing classes. This means providing a way to suppress a Japi error that's entirely in the hands of the people who have a motivation to lower the number of Japi errors. Not that I think any Classpath would abuse it, but not everyone has such careful code review to prevent a zero-svuid going in by mistake. Putting it in the invocation of Japize has the advantage that the knowledge of what's not serializable gets encoded in the *JDK* japi, not the classpath one. I'll see if I can come up with a procedure by which we can check exactly which classes the warning applies to. By the way, this technique *can* be applied to other situations too. The syntax is "-pkg.name,ClassName:serial" where the ",ClassName" is optional. The named class, and all its subclasses, will be treated as not serializable. This gives a lot of flexibility - for example, if it were discovered that the warning only shows up on JComponent and its subclasses, "-javax.swing,JComponent:serial" would do exactly what we want. And if you're comparing something other than the standard API, you can make use of it there too. Stuart. -- http://sab39.dev.netreach.com/
