Recent changes to ClassLoader

ClassLoader modified by Small SQL

Small SQL — Sun, 29 Jun 2014 06:24:31 -0000

--- v11
+++ v12
@@ -54,6 +54,8 @@
     ikvm.runtime.Startup.addBootClassPathAssemby(Assembly.Load("YourDll"));

+The class ikvm.runtime.Startup is saved in IKVM.OpenJDK.Core.dll. 
+
 ## Context class loader

 If you use one of the 3 class loaders for multiple DLL's then this has an effect to the default class loader. But Java know also the concept of the context class loader per thread. The standard class loader use the hierarchical class loader first and then the context class loader.

ClassLoader modified by Small SQL

Small SQL — Sun, 29 Jun 2014 06:24:31 -0000

--- v10
+++ v11
@@ -1,8 +1,4 @@
-[TOC]
-
-# ClassLoader
-
-The class path or the usage of ClassLoaders is a little difficult because Java and .NET are not compatible. 
+The class path or the usage of ClassLoaders is a little difficult because Java and .NET are not compatible. This results mostly in a [ClassNotFoundException].

 In Java you can set the class path with: 

@@ -12,6 +8,10 @@
   * Use a URLClassLoader or your own ClassLoader 

 This is a little different in .NET which can produce class loading problems. 
+
+[TOC]
+
+# Compile time solutions

 ## One large assembly

@@ -45,8 +45,14 @@
     ikvmc -classloader:ikvm.runtime.ClassPathAssemblyClassLoader MyJar.jar

-  
+# Runtime solutions

+## BootClassPathAssemby
+
+If you have a Visual Studio project then it does not help if you add the needed dlls as reference. You need also to use it. But an internal, dynamic use with Class.forName(x) can not detect as usage from Visual Studio. If you have a main program written in .NET then you can register your dll with the follow program line at startup of your program. 
+    
+    ikvm.runtime.Startup.addBootClassPathAssemby(Assembly.Load("YourDll"));
+    

 ## Context class loader

@@ -57,7 +63,7 @@
     Class.forName( "org.company.abc.DynamicLoadedClass", true, Thread.currentThread().getContextClassLoader() );

-If you does not set the context class loader then it point to your main assembly and all assembly that are referenced from the compiler. Typical this means you can load all classes from your main assembly and from the first Java dll which you call directly. 
+If you does not set the context class loader then it point to your main assembly and all assembly that are referenced from the compiler. Typical this means you can load all classes from your main assembly, the BootClassPathAssemby and from the first Java dll which you call directly. 

 You can add references to all DLL's in your main assembly with lines like:

ClassLoader modified by Small SQL

Small SQL — Sun, 29 Jun 2014 06:24:31 -0000

--- v9
+++ v10
@@ -45,6 +45,32 @@
     ikvmc -classloader:ikvm.runtime.ClassPathAssemblyClassLoader MyJar.jar

+  
+
+
+## Context class loader
+
+If you use one of the 3 class loaders for multiple DLL's then this has an effect to the default class loader. But Java know also the concept of the context class loader per thread. The standard class loader use the hierarchical class loader first and then the context class loader. 
+
+There are some bad design Java library which only use the context class loader. This look like: 
+    
+    Class.forName( "org.company.abc.DynamicLoadedClass", true, Thread.currentThread().getContextClassLoader() );
+    
+
+If you does not set the context class loader then it point to your main assembly and all assembly that are referenced from the compiler. Typical this means you can load all classes from your main assembly and from the first Java dll which you call directly. 
+
+You can add references to all DLL's in your main assembly with lines like: 
+    
+    GC.KeepAlive(typeof(org.company.abc.DynamicLoadedClass));
+    
+
+This can be difficult if you have a large count of DLLs. Another solution is to set the context class loader to the same as the default class loader before you load the first class. 
+    
+    java.lang.Class clazz = typeof(org.company.xyz.FirstClass);
+    java.lang.Thread.currentThread().setContextClassLoader( clazz.getClassLoader() );
+    new org.company.xyz.FirstClass();
+    
+
 ## URLClassLoader

 Of course, you can also reuse existing class loader classes. Here's an example with URLClassLoader:

ClassLoader modified by Jeroen Frijters

Jeroen Frijters — Sun, 29 Jun 2014 06:24:31 -0000

--- v8
+++ v9
@@ -54,8 +54,15 @@
       MyCustomClassLoader(cli.System.Reflection.Assembly asm)
       {
         super(new java.net.URL[0], new ikvm.runtime.AssemblyClassLoader(asm));
-        // see below why calling addURL() is safer than passing it to the super constructor
+        // explicitly calling addURL() is safer than passing it to the super constructor,
+        // because this class loader instance may be used during the URL construction.
         addURL(new java.net.URL("..."));
       }
     }

+
+## Related blog entries
+
+  * [Class Loading Architecture](http://weblog.ikvm.net/PermaLink.aspx?guid=4e0b7f7c-6f5d-42a3-a4d6-5d05a99c84ff)
+  * [New Development Snapshot](http://weblog.ikvm.net/PermaLink.aspx?guid=8a457a80-1e5f-4182-8f78-b2cd67845553)
+  * [Writing a Custom Assembly Class Loader](http://weblog.ikvm.net/PermaLink.aspx?guid=375f1ff8-912a-4458-9120-f0a8cfb23b68)

ClassLoader modified by Small SQL

Small SQL — Sun, 29 Jun 2014 06:24:31 -0000

--- v7
+++ v8
@@ -15,7 +15,7 @@

 ## One large assembly

-The simplest solution is to compile all with IKVMC in a single assembly. There is no class loading problem in this case. The disadvantages are: 
+The simplest solution is to compile all with [Ikvmc] in a single assembly. There is no class loading problem in this case. The disadvantages are: 

   * a performance degree, you need to load all possible components. For example all supported JDBC driver if you only need one at one moment. 
   * duplicate resources files are lost. Like in one jar also in one dll a single file can exist only once. If the resources identical it is no problem. But with service for dynamic loading of components it is fatal. For example a JDBC driver registers it self if it in the classpath. If you have multiple JDBC drivers then only one is registers.

ClassLoader modified by Small SQL

Small SQL — Sun, 29 Jun 2014 06:24:30 -0000

--- v6
+++ v7
@@ -37,3 +37,25 @@

 You can only share the classloader between the jar files that was create in one step. 
+
+## ClassPathAssemblyClassLoader
+
+It first searches the assembly (and, again, the assembly directly referenced) and then the class path. 
+    
+    ikvmc -classloader:ikvm.runtime.ClassPathAssemblyClassLoader MyJar.jar
+    
+
+## URLClassLoader
+
+Of course, you can also reuse existing class loader classes. Here's an example with URLClassLoader: 
+    
+    class MyCustomClassLoader extends java.net.URLClassLoader
+    {
+      MyCustomClassLoader(cli.System.Reflection.Assembly asm)
+      {
+        super(new java.net.URL[0], new ikvm.runtime.AssemblyClassLoader(asm));
+        // see below why calling addURL() is safer than passing it to the super constructor
+        addURL(new java.net.URL("..."));
+      }
+    }
+

ClassLoader modified by Small SQL

Small SQL — Sun, 29 Jun 2014 06:24:30 -0000

--- v5
+++ v6
@@ -21,8 +21,12 @@
   * duplicate resources files are lost. Like in one jar also in one dll a single file can exist only once. If the resources identical it is no problem. But with service for dynamic loading of components it is fatal. For example a JDBC driver registers it self if it in the classpath. If you have multiple JDBC drivers then only one is registers.

 ## AppDomainAssemblyClassLoader
+
+This classloader loads from all assemblies that are currently loaded in your application (AppDomain in .NET lingo). So if a referenced assembly has not yet been loaded, it will not be searched at least not by the "AppDomain" part of the class loader, the default assembly class loader mechanism will still load referenced assemblies that are *directly* referenced by your assembly. 
+
+You can set it with the follow command line: 

-    ikvmc -classloader:ikvm.runtime.AppDomainAssemblyClassLoader
+    ikvmc -classloader:ikvm.runtime.AppDomainAssemblyClassLoader MyJar.jar

 ## sharedclassloader

ClassLoader modified by Small SQL

Small SQL — Sun, 29 Jun 2014 06:24:30 -0000

--- v4
+++ v5
@@ -31,3 +31,5 @@

     ikvmc -sharedclassloader { first.jar } { second.jar } { third.jar }

+
+You can only share the classloader between the jar files that was create in one step.

ClassLoader modified by Jeroen Frijters

Jeroen Frijters — Sun, 29 Jun 2014 06:24:30 -0000

--- v3
+++ v4
@@ -13,9 +13,9 @@

 This is a little different in .NET which can produce class loading problems. 

-## One large assemblies
+## One large assembly

-The simplest solution is to compile all with IKVMC in a single assemblies. There is no class loading problem in this case. The disadvantages are: 
+The simplest solution is to compile all with IKVMC in a single assembly. There is no class loading problem in this case. The disadvantages are: 

   * a performance degree, you need to load all possible components. For example all supported JDBC driver if you only need one at one moment. 
   * duplicate resources files are lost. Like in one jar also in one dll a single file can exist only once. If the resources identical it is no problem. But with service for dynamic loading of components it is fatal. For example a JDBC driver registers it self if it in the classpath. If you have multiple JDBC drivers then only one is registers.

ClassLoader modified by Small SQL

Small SQL — Sun, 29 Jun 2014 06:24:30 -0000

--- v2
+++ v3
@@ -1,3 +1,5 @@
+[TOC]
+
 # ClassLoader

 The class path or the usage of ClassLoaders is a little difficult because Java and .NET are not compatible. 
@@ -11,11 +13,21 @@

 This is a little different in .NET which can produce class loading problems. 

-## One large file
+## One large assemblies

-The simplest solution is to compile all with IKVMC in a single dll or exe. There is no class loading problem in this case. The disadvantages are: 
+The simplest solution is to compile all with IKVMC in a single assemblies. There is no class loading problem in this case. The disadvantages are: 

   * a performance degree, you need to load all possible components. For example all supported JDBC driver if you only need one at one moment. 
   * duplicate resources files are lost. Like in one jar also in one dll a single file can exist only once. If the resources identical it is no problem. But with service for dynamic loading of components it is fatal. For example a JDBC driver registers it self if it in the classpath. If you have multiple JDBC drivers then only one is registers. 

+## AppDomainAssemblyClassLoader
+    
+    ikvmc -classloader:ikvm.runtime.AppDomainAssemblyClassLoader
+    
+
 ## sharedclassloader
+
+If you compile multiple jar files to multiple assemblies then you can use the option sharedclassloader. 
+    
+    ikvmc -sharedclassloader { first.jar } { second.jar } { third.jar }
+