XOM API for Processing XML with Java

[Remko Popma <remko.popma AT azzurri.jp>]

--- Elliotte Rusty Harold <elharo AT metalab.unc.edu> wrote:
> 
> At 10:33 AM +0200 9/19/02, Laurent Bihanic wrote:
> 
> 
> >  - ClassLoader issues: Type-safe enumerations, such as 
> >Attribute.Type, do not fit well with class loaders, even when 
> >implementing equals() (see 
> >http://www.javaworld.com/javatips/jw-javatip122_p.html).
> >
> 
> This is an issue. I'm not sure what to do about it. Last night I 
> reread the Bloch section on type-safe enums and he does not address 
> this point at all. Certainly class loaders can be a problem in 
> servlet containers, IDEs, and more. I've encountered this personally.
> 
> Here's one possibility: I add an equals() method to the 
> Atrribute.Type class that can be used if client code is likely to be 
> in a multi-loader environment. That would make the implementation 
> more complex. I don't want to go to a straight int enum because 
> type-safety is important to me. Thoughts?
> -- 

1) Is this really a typesafe enum issue?
Basically, as far as I understand it, neither the == operator nor the
equals() method works if you compare two instances loaded by separate
classloaders. So eg. someNode.equals(sameNodeLoadedByOtherClassloader)
would also return false. If this is an issue you'd have to rethink the
implementation of *every* equals() method. How paranoid do we need to be?

2) Typesafe enums offer a cleaner, more intuitive design than integer
constants. From the client's point of view they are easier to use
(more difficult to do it wrong), and I've often found that using 
this pattern paves the way for other refactorings that improve the code 
or the design or both.

3) What are the design priorities?
Does XOM have to be made to work in a distributed environment?
Even though thread-safety, a more common design goal, is explicitly not a XOM 
design goal?