Re: [Ikvm-developers] Fw: classpath issue after migrating from v30 to v34

[Jeroen F. <je...@su...>]

Hi Jonathan,

Sorry for my snarky reply yesterday.

jon...@hs... wrote:
> I am suggesting that you can stick with the current design and add a
> fallback case that enables greater compatbility with the Java model.
> So it is not a disagreement as such, but rather expanding on the
> existing scheme.

It's not that simple. The previous model of checking all loaded assemblies =
is *fundamentally* broken (it was broken when I originally "designed" it, b=
ut changes in .NET 2.0 made it even more broken). In addition to that it al=
so has horrible performance implications.

Now this wouldn't be so bad if the Java class loading architecture wasn't a=
lso fundamentally broken. The way class loader delegation works would mean =
that every class that is dynamically loaded would first trigger a search th=
rough every loaded assembly, it can't work as a "fallback case" as you sugg=
est.

My plan to (hopefully) solve the assembly class loader issues all at once, =
is to add an option to ikvmc that allows you to override the assembly class=
 loader, in much the same way as you can override the system class loader i=
n Java, by setting the java.system.class.loader system property.

When I do this, I will probably also provide a few standard replacement ass=
embly class loaders that provide commonly requested functionality, but if t=
hey don't do what you want you can write your own class loader and complete=
ly replace the behavior for dynamic class loading and resource loading for =
your assembly.

Regards,
Jeroen