Re: context classloader

On Tuesday 18 January 2005 23:12, Oliver Jowett wrote:
> Ok, but I don't understand why you'd want to jump through all these
> hoops in the first place.

Because you may want to be a good citizen in the app server world,
where defaulting to the system classloader still seems suboptimal to
me. This use case has been adequately addressed in your reply though.
I don't want to press this line of reasoning any further.

> It is even less predictable when the static initializer will be run
> (and therefore what the CCL will be set to at that point). What's
> the point?

The same goes for getClass().getClassLoader(). It's not predictable
what this returns.

> It's the logical conclusion of using the CCL to find the defaults.

I don't see how that follows.

> What is special about [...] the first action that happens to cause
> class initialization (if you go with magic in the static
> initializer)?

It's special because it determines the result of
getClass().getClassLoader(). In other words, it's special because
current code treats as such:

Enumeration urls = getClass().getClassLoader().
getResources("/org/postgresql/driverconfig.properties");

For the sake of completeness, what do you think of doing nothing in
the case when the driver is loaded by the bootstrap classloader? In
other words, wrap the affected chunk of code in the following
conditional:

if (getClass().getClassLoader() != null) {
// load the /org/postgresql/driverconfig.properties files
}

Thanks,
Vadim

P.S.

> > (BTW, couldn't this be Driver.class.getClassLoader() instead?)
>
> Yes. getClass() tends to be a bit friendlier to anything that tweaks
> the bytecode, though, since a .class reference compiles down to a
> call to Class.forName() which breaks if the class is renamed, etc.

Out of curiosity, is it a formal policy of the pgsql-jdbc project to
be friendly to bytecode mungers? What other guidelines does one need
to be mindful of?