kyt 0 Report post Posted May 20, 2008 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 Share this post Link to post Share on other sites
zztop 0 Report post Posted May 21, 2008 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? Share this post Link to post Share on other sites
kyt 0 Report post Posted May 21, 2008 Yes, I was wrong -- small confusion with the "protect/not required" settings. Thanks Share this post Link to post Share on other sites
kyt 0 Report post Posted June 2, 2008 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. Share this post Link to post Share on other sites
zztop 0 Report post Posted June 3, 2008 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 Share this post Link to post Share on other sites
kyt 0 Report post Posted June 3, 2008 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 Share this post Link to post Share on other sites
kyt 0 Report post Posted June 3, 2008 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" Share this post Link to post Share on other sites
zztop 0 Report post Posted June 3, 2008 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. Share this post Link to post Share on other sites
kyt 0 Report post Posted June 3, 2008 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. Share this post Link to post Share on other sites
snowman 0 Report post Posted June 4, 2008 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. Share this post Link to post Share on other sites
kyt 0 Report post Posted June 4, 2008 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 Share this post Link to post Share on other sites
kyt 0 Report post Posted June 4, 2008 ...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. Share this post Link to post Share on other sites
kyt 0 Report post Posted July 7, 2008 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. Share this post Link to post Share on other sites
kyt 0 Report post Posted July 7, 2008 BTW, I ran it on Ubuntu 8.04, if that helps. Oh, and should be pronounced as "eight" (line "eight"). Share this post Link to post Share on other sites
eve 0 Report post Posted July 8, 2008 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? Share this post Link to post Share on other sites
kyt 0 Report post Posted July 8, 2008 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 Share this post Link to post Share on other sites
kyt 0 Report post Posted July 8, 2008 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 Share this post Link to post Share on other sites
kyt 0 Report post Posted July 8, 2008 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. Share this post Link to post Share on other sites
eve 0 Report post Posted July 9, 2008 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. Share this post Link to post Share on other sites
kyt 0 Report post Posted July 9, 2008 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. Share this post Link to post Share on other sites
eve 0 Report post Posted July 10, 2008 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? Share this post Link to post Share on other sites
kyt 0 Report post Posted July 10, 2008 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! Share this post Link to post Share on other sites
kyt 0 Report post Posted July 18, 2008 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 Share this post Link to post Share on other sites
eve 0 Report post Posted July 21, 2008 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. Share this post Link to post Share on other sites
kyt 0 Report post Posted January 7, 2009 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. Share this post Link to post Share on other sites