Posted 20 May 2008 - 08:36 PM
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?
Posted 21 May 2008 - 05:00 AM
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.
Why do you ask? ;)
Posted 02 June 2008 - 11:28 PM
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.
Posted 03 June 2008 - 06:52 AM
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).
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.
If you have an active Support Contract, it will be free.
Posted 03 June 2008 - 04:59 PM
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
b) 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"?
Posted 03 June 2008 - 06:32 PM
I guessed. 8)
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.
Posted 03 June 2008 - 10:16 PM
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.
Posted 04 June 2008 - 03:48 AM
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.
Posted 04 June 2008 - 04:19 PM
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.
Posted 07 July 2008 - 11:00 PM
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 8): 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:
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.
Posted 08 July 2008 - 03:07 PM
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.
Posted 08 July 2008 - 06:59 PM
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?
Posted 08 July 2008 - 10:45 PM
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.
Posted 09 July 2008 - 05:16 AM
Well, Excelsior JET User's Guide is a bit confusing at this point, but it clearly states that
Subsequent remarks about pathname imply that you can specify a relative pathname rather than an absolute path to the shared library.
Posted 09 July 2008 - 04:46 PM
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.