Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.CARNet.hr!garrison.bnet.hr!gregory.BNet.hr!not-for-mail
From: Josip Almasi <joe@vrspace.org>
Newsgroups: comp.lang.java.programmer
Subject: Re: dealing with ClassLoaders...
Date: Fri, 08 Aug 2014 11:53:36 +0200
Organization: B.net Hrvatska d.o.o.
Lines: 58
Message-ID: <ls26n0$jrp$1@gregory.bnet.hr>
References: <slrnltl6t2.fp3.avl@login.logic.tuwien.ac.at> <lrg69c$6r3$1@gregory.bnet.hr> <slrnltv8mj.fp3.avl@login.logic.tuwien.ac.at>
NNTP-Posting-Host: cpe-94-253-154-252.zg.cable.xnet.hr
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: gregory.bnet.hr 1407491616 20345 94.253.154.252 (8 Aug 2014 09:53:36 GMT)
X-Complaints-To: abuse@globalnet.hr
NNTP-Posting-Date: Fri, 8 Aug 2014 09:53:36 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
In-Reply-To: <slrnltv8mj.fp3.avl@login.logic.tuwien.ac.at>
Xref: csiph.com comp.lang.java.programmer:29583

On 08/04/2014 05:12 PM, Andreas Leitgeb wrote:
> Josip Almasi <joe@vrspace.org> wrote:
>> On 07/31/2014 09:40 PM, Andreas Leitgeb wrote:
>>> The classloader tutorials I skimmed so far seem to imply, that
>>> a custom classloader is only appropriate to enable classloading
>>> from sources that the system classloader cannot handle itself.
>> Nah, it's also appropriate for context isolation.
>
> But it seems like it doesn't really make it easy to use it
> that way.

Noone said it's easy;)


>>> 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?
>> Yep, just don't break delegation model.
>> Model says something like, a classloader should ask parent classloader
>> if it has already loaded the class.
>> So, make sure you respect that rule.
>
> The twist in my case comes from the fact, that the parent *could*
> theoretically have loaded one of my special classes, but that would
> just indicate a programming error (aka Bug), so I'd rather have the
> compiler or at least the VM report a strange ClassCastException
> than silently use one of my classes loaded by wrong classloader.

Don't worry, it won't be silent:>
Mess up anything, and you get strange ClassCastExceptions.

>> Also, make sure your loaders don't load the same packages.
> This I don't understand.
> While my "special classes" happen to be in a specific package,
> I don't see, why packages as such would be relevant. I'd expect
> that even within the same package I should (in principle) be
> allowed to have some classes loaded through parent and others
> through custom classloader.

Well your classes 'happen' to be in specific packages, but I think you 
should use that to your advantage, to avoid confussion and classloader bugs.
It gets ugly when equals() starts throwing up.
Better have clearly divided responsibilities.

> I'd welcome hints for how to improve the "classname -> byte[]" step.

I used something like

JarEntry entry = (JarEntry) jarFile.getEntry( name+".class" );
InputStream stream = jarFile.getInputStream(entry);
int size = (int) entry.getSize();
byte[] code = new byte[size];

I also stated with URL but gave it up, because of unknown length.
If I really wanted to load classes remotelly, I'd download jars first 
then load classes from local copies.

Regards...