> i thought graph isomorphism was np-complete though? so its likely that even
> if the trouble of implementing this was gone through it wouldn't be worth
> it in general (?)
I don't think it is NP-complete. Perhaps you are thinking about a
general graph isomorphism problem, but the problem we have is easier (in
the sense that edges are labeled.)
But you raised a good point about the overhead of computing
hashCode/equality. Since we have to traverse the entire sub-tree, it
seems like the cost could be very expensive (even if the theoretical
complexity is not NP-complete.)
> What do you make of the argument that cyclic XML is such a rarity that it
> would be reasonable to ignore it, at least for a first release of equals()
> and hashCode() definitions? its a
> very practical point of view that might catch most JAXB users problems.
I don't consider it as "such a rarity." As I pointed out, ID/IDREFs
introduce cycles and they are quite common.
> (The code I'm working on needs to put a number of xml elements into a
> java.util.Set - which fails without hashCode() implemented in some way or
> another)
It will break as soon as you start modifying those XML elements.
Could you also elaborate on why you want to put those on Set?
> So a third alternative (other than StackOverflowError/graph-isomorphism)
> for implementing equality/hashCode would also be to detect and complain
> also?
Could be.
regards,
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net