Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #29490

Re: dealing with ClassLoaders...

Show key headers only | View raw

Chris Uppal <chris.uppal@metagnostic.REMOVE-THIS.org> wrote:
> Andreas Leitgeb wrote:
>> Is there a clean way to keep classes of a given package confined
>> to some custom classloader, in order to control the classes' and
>> their statics' scope/lifetime?
> It's a long time since I last messed with classloaders, but from memory the 
> only safe way to ensure that your custom-classloader classes aren't loaded from 
> the system default classloaders is to ensure that they are not on the classpath 
> (or anywhere else the "main" classloaders look).

Well, I've heard that there were some crocodiles in the custom-classloader
swamp, but for now I'm positive that I can avoid getting eaten.

Static fields are a programming convenience at a highly volatile price.
One may get away with a peanuts-price if one is lucky, but eventually the
price may rise on each drop of an original assumption.

I had to drop some assumptions, but not yet all. As of now I think I can
still afford the price of some static fields, and will try to get rid of 
most others.  Eventually I even might be able to get rid of the rest
until I reach the ideal of no static mutable state. It just won't happen
at once, and I'll need custom classloaders during that (open-ended)
transition.

>> The outset is, that some of these classes contain static data.
>> (They had been designed as standalone application classes.)
>> Now, to improve invocation time, one VM is supposed to run all
>> the program instances.
>
> If you just let your main "server" process load all the classes upfront (no 
> custom classloaders at all) then you'll take the initialisation time hit just 
> once as it stars.

Indeed, but that would pre-require completion of abovementioned transition.

>  If you use custom classloaders with one for each "client" 
> you'll take a partial hit for every client instance, and you'll lose 
> data-sharing between instances.

data-sharing between clients is not an issue in my case, and I expect the
partial hit to gradually disappear along the path of transition.

>   From what I remember of your earlier thread 
> you wanted extremely fast startup for the "clients", in which case the 
> just-get-it-over-with-when-the-server-starts approach might well make more 
> sense (and be simpler too).

Extremely fast... yes, who doesn't? I think for now the jvm itself is the
bottleneck here, and those few extra classes loaded for a new client
will be neglectible for the time being...

Thanks for your answer, especially for the heads-up w.r.t dangers with
classloaders (classes accidentally getting loaded through system classloader).
I'd better afford some assertions in my code... kind of tripwires in some
classes that will ring the alarm-bells, if their classloader happens to be
identical to getSystemClassLoader().  The one thing worse than the problem
itself is not being aware of it happening.

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-07-31 19:40 +0000
  Re: dealing with ClassLoaders... Martin Gregorie <martin@address-in-sig.invalid> - 2014-07-31 20:44 +0000
    Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 14:22 +0000
      Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 21:10 +0000
        Re: dealing with ClassLoaders... Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-08-01 17:32 -0400
          Re: dealing with ClassLoaders... Joerg Meier <joergmmeier@arcor.de> - 2014-08-02 01:21 +0200
          Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-02 00:00 +0000
        Re: dealing with ClassLoaders... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-01 21:45 +0000
          Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 23:14 +0000
            Re: dealing with ClassLoaders... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-02 00:35 +0000
              Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-05 15:38 +0000
  Re: dealing with ClassLoaders... Silvio <silvio@internet.com> - 2014-08-01 13:31 +0200
    Re: dealing with ClassLoaders... Silvio <silvio@internet.com> - 2014-08-01 13:37 +0200
      Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 16:06 +0000
  Re: dealing with ClassLoaders... "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-01 13:19 +0100
    Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-01 15:51 +0000
  Re: dealing with ClassLoaders... Josip Almasi <joe@vrspace.org> - 2014-08-01 15:55 +0200
    Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-04 15:12 +0000
      Re: dealing with ClassLoaders... Mike Amling <mamling@chaff.us> - 2014-08-04 19:53 -0500
        Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-05 15:16 +0000
      Re: dealing with ClassLoaders... Josip Almasi <joe@vrspace.org> - 2014-08-08 11:53 +0200
        Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-08 18:46 +0000
          Re: dealing with ClassLoaders... Josip Almasi <joe@vrspace.org> - 2014-08-10 13:22 +0200
            Re: dealing with ClassLoaders... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-12 17:16 +0000

csiph-web