external libs

[kyt 0]

Hello,

Excelsior compiles in classes from jars specified on the class path.  Then JetPack requires ALL external lib jars (with .class files) to be included in the installation package.

I think I got it right.

So, my question: is there a way NOT to include the external libs (jars with .class files) in the installation package, since they are already compiled in?  That would help a lot.

Also, when is the next release of Excelsior Jet scheduled?

Thanks

[zztop 0]

Excelsior compiles in classes from jars specified on the class path.  Then JetPack requires ALL external lib jars (with .class files) to be included in the installation package.

I think I got it right.

No, that's not right. JetPackII does not require inclusion of pre-compiled jars into the package. Why do you think so?

The only exception is libraries whose implementation requires presence of the original class files at run time (that's not about JetPackII, that's about the libraries).

For instance, Java Crypto Extensions also known as security providers check the sizes of their class files during execution. In such cases, the class files serve as both program code and resources. Therefore,  despite all the classes are pre-compiled, you have to make them available to the running application. Adding such jar files to the package resolves the problem.

------------

Also, when is the next release of Excelsior Jet scheduled?

Why do you ask?

[kyt 0]

Yes, I was wrong -- small confusion with the "protect/not required" settings.

Thanks

[kyt 0]

Why do you ask? Wink

I want to figure out if I should start creating a purchase requisition now or wait a little for possible new features like multi-component application support.  So, will there be this feature in the new release?

It would be nice to look at the list of the features planed for the next release.

I know we can upgrade later, but I guess that's not free.  :'(

If you don't really want to reply, that's OK - I can understand.

[zztop 0]

I want to figure out if I should start creating a purchase requisition now or wait a little for possible new features like multi-component application support. 

Multi-component applications are supported since the first version of Excelsior JET. You must mean ease-of-use not support. For instance,  the JET Control Panel could assist you in the separating of your applications into executable and DLLs (shared libs).

So, will there be this feature in the new release?

No, it's not planned. I know four reasons why customers may wish to create multi-component apps:

1) faster builds - you may place  some (unchanged) jars, such as Apache Commons, into a DLL and rebuild only the application code

Smart compilation addresses the problem without the mess with EXE and DLLs. We are working on the imlementation of the smart mode in the Optimizer

2) smaller updates - again you may include only the modified component (executable) in the update package

In the same vein, in our opinion, this task is for JetPackII not for the end user. It can be implemented through an advanced technique of binary comparison which is conscious of the structure of the the JET-compiled executables.

We are working on it as well and the conducted experiments showed very promising results.

3) deployment of several applications sharing some common libraries

Provided p1 and p2 above are implemented, the apps can be compiled into a single executable that can be run with different command line arguments. Another option: several small executables that contain only the main classes and one DLL.  Unlike general case, the setup of project files for such configuration is quite simple. 

4) separate deployment of the application components in the compiled form

This is the only "good" reason for creation of multi-component apps and this scenario cannot be replaced with other (easier to use) scenarios. Basically, it can be done now through the command line interface to the JET Optimizer though GUI tools may help you in it to some extent as described in the JET User's Guide (chapter "Dynamic Linking", section "Multi-component applications").

Note also that introducing Project Data Bases and the "!uses" directive of the project file (available since Excelsior JET 5.0) made this task mush easier.

------------------

If you know other reasons for creation of multi-component apps, please share your opinion.

------------------

I know we can upgrade later, but I guess that's not free.

If you have an active Support Contract, it will be free.

--ZZ Top

[kyt 0]

You must mean ease-of-use not support

Yes.

We are mainly interested in # 4.

I have another question.  It's about cyclic imports.

Lets say I have:

1) Jar A (main application) which includes

    a) some arbitrary classes

    interface "I"

    c) class "PluginClass" which implements interface "I"

2) Jar B (a plug-in) which extends class "PluginClass"

After the main application loads a class from Jar B and casts it to "PluginClass", the newly created plug-in object (PO) can use classes from Jar A and at the same time classes from Jar A can use PO to call methods defined in Interface "I".

Would this scenario be considered as "cyclic imports"?

Thank you

[kyt 0]

2) Jar B (a plug-in) which extends class "PluginClass"

I meant: 2) Jar B (a plug-in) which has a class that extends class "PluginClass"

[zztop 0]

I meant: 2) Jar B (a plug-in) which has a class that extends class "PluginClass"

I guessed. 

-------

No, it's not cyclic import.

Under the term "import", we mean static (compile-time) dependencies between jar files.

In your case, Jar B imports Jar A but not vice versa.

[kyt 0]

OK, thanks.

Another question:

Speaking of run time linking, it's nice that one can use a wild card for the class name (-dll:com.MyCompany.*:MyDll.dll ), but is there a way to do the same for the DLL names?  That would be helpful.

Thank you.

[snowman 0]

I know we can upgrade later, but I guess that's not free.

If you have an active Support Contract, it will be free.

To be more precise, if you don't have an active Support Contract, you cannot upgrade.

A one-year Support Contract is included with the initial license purchase. Then you can renew it for another year and so on.

The above does not apply to Academic licenses.

[kyt 0]

Thank you, showman.

The effect that I would be looking for from "-dll:com.MyCompany.*:MyDll*.dll" is to get my class from the first DLL (which has a name starting with "MyDll") that has that class.

Thanks

[kyt 0]

...moving on to another issue.

The subject is the User Manual/Dynamic linking/Multi-component applications.

I do not understand the relationship between Step 2 and Step 3. 

I assume that  Step 2 should result in creation of new project files (CS1.prj,...)  .

If that is so, what should I do with them later?  Should I merge them with the project files (CS_1.prj,...) created in Step 3?

Please let me know what I'm missing here.  Thank you.

[kyt 0]

OK, after reading again I suspect that CS1.prj is created to be referenced (by the means of "!uses" directive) in CS_2.prj or some other prj that depends on CS1.prj.

So I created a project for the main application (Main) that would load plug-ins at run time.  Plug-ins depend on Main -- they extend some classes found in Main; and now I want to generate a native library (compiled plug-in).  I go to STEP 3 (after completing 1 and 2) and create test.prj with a directive "!uses /.../.../Main.prj".  I think this is how it should be done. 

Well I did that and when I tried to compile the project I got some errors:

#########################################

Excelsior JET v6.4 Standard Edition © Excelsior 1997,2008

Active Java SE Version 1.6.0_07 (profile 7)

Make project "test.prj"

#file "test.prj" (line : syntax error

#file "test.prj" (line 11): syntax error

#file "test.prj" (line 12): syntax error

#file "test.prj" (line 13): syntax error

#classpath entry not found ""

Total compilation time 0:00.02

#########################################

Here is the test.prj file:

#########################################

-OUTPUTNAME=testPlugin

-GENDLL+

-CLASSABSENCE=HANDLE

-IGNOREMEMBERABSENCE+

-LOOKUP=*.jar=/home/k/java_projects

!uses /home/k/java_projects/prj1/prj1.prj

!CLASSPATHENTRY /home/k/java_projects/test/testPlugin.jar

   -PACK=NONCOMPILED

   -OPTIMIZE=ALL

   -PROTECT=ALL

!END

#########################################

Note that "/home/k/java_projects/test/testPlugin.jar" file is 100% there. 

Can anyone tell me what is wrong with that project file?

Thanks a bunch.

 

[kyt 0]

BTW, I ran it on Ubuntu 8.04, if that helps.

Oh, and  should be pronounced as "eight" (line "eight").

[eve 0]

Can anyone tell me what is wrong with that project file?

These errors are really confusing. Could please send all your project files (test.prj, prj1.prj) as attachments to java (at) excelsior-usa.com?

[kyt 0]

All is well now.

What happened is that I copied (ctrl+c) the project file template from the user's guide and pasted it into gedit and then added new line characters by hand. That did not work.

Then I typed the whole file by hand in a new gedit document and everything worked fine.

Probably some characters that jc needed where missing or there where some extra ones that jc did not like.

Thanks

[kyt 0]

All right, I compiled .so and used it as a plug-in.  Everything works OK.

There were however some issues:

1) It took me a while to figure out that JETVMPROP is already defined in Main project.  When I tried to start the application from a script where  JETVMPROP was defined for DLL mapping, the  JETVMPROP defined in Main project was overwritten and nothing worked.

2) It turns out that specifying an incomplete path for a DLL does not work at all.  For example, "-dll:asnt.*:lib" or "-dll:asnt.*:./lib" don't work.  I must specify the full name of the library: "-dll:*:lib/testPlugin.so".  Otherwise, my classes are not found.  This a very serious limitation for us.  Can this problem be solved?

Thank you

[kyt 0]

It turns out that specifying an incomplete path for a DLL does not work at all.

I should note that this applies to Linux only -- the user's guide for Linux Jet indicates/implies that incomplete library path names may contain just a directory name (e.g, "./lib").

Adding the "lib" directory to PATH does not work either.

Testing for Windows is tomorrow.

[eve 0]

I should note that this applies to Linux only -- the user's guide for Linux Jet indicates/implies that incomplete library path names may contain just a directory name (e.g, "./lib").

Well, Excelsior JET User's Guide is a bit confusing at this point, but it clearly states that

dll-name is the name of the shared library containing the class class-name or classes whose fully qualified names begin with class-prefix.

Subsequent remarks about pathname imply that you can specify a relative pathname rather than an absolute path to the shared library.

[kyt 0]

OK,

so are we going to see a fix for this problem or do we have to think about an alternative design?

To be clear, I will rephrase my concern/wish:

I want to put my .so file into a directory next to the executable that loads classes from that .so file.  I would name that directory "lib", for example.  Then I want to give JETVMPROP the value that contains "-dll:*:lib" and have the executable load my classes from any .so file in "lib" directory. 

I'm saying "fix for this problem", because the use'r guide states/implies such possibility on Linux.

In Windows case this would rather be an enhancement, because the user's guide indicates that exact DLL names should be supplied. 

Anyway, we want to be more flexible with our libraries.  So, please can you give it a though, if possible?

Thank you very much.

[eve 0]

so are we going to see a fix for this problem

Sure, we will definitely fix the documentation to make it less confusing

I want to put my .so file into a directory next to the executable that loads classes from that .so file.  I would name that directory "lib", for example.  Then I want to give JETVMPROP the value that contains "-dll:*:lib" and have the executable load my classes from any .so file in "lib" directory. 

This will significantly degrade startup time and overall performance of your application.

Still you may try to emulate required behavior through the following method:

void registerPlugins() {
    String pluginsDir = "lib";
    String dlls[] = new File(pluginsDir).list(
        new FilenameFilter() {
            public boolean accept(File dir, String name) {
                return name.endsWith(".so");
            }
        });       
    for(String dll : dlls) {
        System.load(new File(pluginsDir, dll).getAbsolutePath());
    }
}

Just call it before any attempts to load classes from your libraries.

Does this solution satisfy your needs?

[kyt 0]

This will significantly degrade startup time and overall performance of your application.

We load plug-ins after start-up when the main system receives the info from outside about what classes to load.

Anyway, you gave us a good solution.  Thank you! 

[kyt 0]

Is it possible to to slightly modify a .prj file (change outputname and add some jars) save it as "newproject.prj", build a new executable and then run the new executable which loads a DLL that was built  with "!uses oldproject.prj" directive? The classes in the DLL are programmatically compatible with both exe-s -- the additional jars do not affect DLL-to-exe interaction.

I have tried to do it, but I get this message: "Runtime error #4(trap, xrXTables.mod:180). Please contact Excelsior ..."

I don't understand  what is going on.  Can you help?  Thanks

[eve 0]

Is it possible to to slightly modify a .prj file (change outputname and add some jars) save it as "newproject.prj", build a new executable and then run the new executable which loads a DLL that was built  with "!uses oldproject.prj" directive?

No. You should keep projects in sync. If you recompile some project you should recompile all projects that reference it through !uses directive.

If executable X loads DLL Y then project for Y should reference project for X not some other project.

[kyt 0]

No. You should keep projects in sync. If you recompile some project you should recompile all projects that reference it through !uses directive.

Can you tell me how strict is this policy?

I have been able to recompile the main project and use the old dependent DLL's without problems. 

Thank you.