[
Lists Home |
Date Index |
Thread Index
]
- From: David Brownell <david-b@pacbell.net>
- To: David Megginson <david@megginson.com>
- Date: Mon, 28 Feb 2000 21:06:30 -0800
David Megginson wrote:
>
> David Brownell writes:
> > David Megginson wrote:
> > >
> > > David Brownell <david-b@pacbell.net> writes:
> > >
> > > > However, I do wonder what you think about the fact that this will
> > > > need to run in environments where calls like System.getProperty()
> > > > aren't allowed, or which may not support dynamic loading.
> > >
> > > Suggestions?
> >
> > Same approach used in classes like "java.lang.System" -- the API has
> > static class methods, but implementation of the class is unspecified.
> > It varies between environments; the reference implementation can be
> > changed.
>
> That's not a good parallel, though, because there's always only one
> java.lang.System class in any given Java installation (as far as I
> know)
Any given class loader has only one implementation of a class, true.
But my point is that this is for supporting adequate defaulting
in _any_ Java environment.
> -- on the other hand, if I install a future version of both
> IBM's XML4J and James Clark's XP (for example) into the same Java
> installation, then I would get two different versions of
> org.xml.sax.helpers.XMLReaderFactory and whichever happens to be first
> on the classpath will always get hit.
Which would be absolutely no problem, and might even be a benefit.
If you care about which parser you get, then ask for it. Else
you asked for a default, and you got one. Anyone who can control
a system property can do the same to a class path, but the converse
isn't true. Software setting up a controlled environment for running
components (a preferred model) will assemble it at runtime using
class loader primitives and such, but can't set system properties
differently.
- Dave
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************
|