Jump to content
Excelsior Forums
crazyjavahacking

Run-time linking of shared libraries

Recommended Posts

Hi,

I was testing multi-component applications in JET 14 and the documentation is saying:

Quote

The mapping allows the


Class.forName()

method to succeed for classes precompiled into shared libraries loaded at run time. You need to tell the JET runtime in which shared library to look for each class or package. You may do that by adding the following options to the JETVMPROP equation or the JETVMPROP environment variable:


-dll:class-name:dll-name
-dll:class-prefix *:dll-name

 

It looks like that I don't have to use mentioned switch if I put all the compiled *.so shared libraries in the same directory as the binary.

Is that correct? Please verify.

 

Thanks, Martin

Share this post


Link to post
Share on other sites

Hi Martin.

Note that this citation is from section Run time linking and above that the Load time linking and their differences are described.
If you are making a multi-component application following the steps from section 11.3 Multi-component applications of User's Guide, then there are `!uses` directives in your project files. That directive enforces load-lime linking for specified components, so there is no need in provoking run-time linking for them.

Pretty the same is effect of `!module` directive, yet it is more restritive in a way that while `!uses` allows inter-component (but not cyclic) dependecies, for `!module` there must be no static dependencies between libs.

To sum this up, there are three different ways to tell JET-compiled executable about additional classes in a separate library:

  1. `!uses lib1.prj` directive, which provides load-time linking and allows AOT-compiler to see info about classes compiled into lib1 so that it can resolve static dependencies onto them.
  2. `!module lib2.so` directive, which also provides load-time linking but doesn't know anything about how this library were compiled, so cannot provide AOT-compiler with info needed to resolve static dependencies onto classes.
  3. `-dll:class-...:lib3.so` runtime property, which provides run-time linking and thus cannot influent AOT compilation in any way.

Hope this helps, but don't hesitate to ask additional questions if anything not clear enough.

Kind regards,
Igor Jorch,
Excelsior Support.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×