Excelsior Forums: external libs - Excelsior Forums

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

external libs

#1 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 20 May 2008 - 08:36 PM

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


0

#2 User is offline   zztop 

  • Advanced Member
  • Group: Moderators
  • Posts: 331
  • Joined: 09-February 05

Posted 21 May 2008 - 05:00 AM

Quote

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.

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

Quote

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


Why do you ask? ;)

#3 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 21 May 2008 - 04:06 PM

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

Thanks
0

#4 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 02 June 2008 - 11:28 PM

Quote

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.


0

#5 User is offline   zztop 

  • Advanced Member
  • Group: Moderators
  • Posts: 331
  • Joined: 09-February 05

Posted 03 June 2008 - 06:52 AM

Quote

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).

Quote

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.

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

Quote

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

#6 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 03 June 2008 - 04:59 PM

Quote

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
    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"?

Thank you

0

#7 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 03 June 2008 - 06:29 PM

Quote

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"
0

#8 User is offline   zztop 

  • Advanced Member
  • Group: Moderators
  • Posts: 331
  • Joined: 09-February 05

Posted 03 June 2008 - 06:32 PM

Quote

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


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.

#9 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 03 June 2008 - 10:16 PM

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.




0

#10 User is offline   snowman 

  • Advanced Member
  • Group: Moderators
  • Posts: 327
  • Joined: 10-May 02

Posted 04 June 2008 - 03:48 AM

Quote

Quote

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.
Other resources:
Excelsior JET: FAQ | Knowledge Base

#11 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 04 June 2008 - 04:17 AM

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
0

#12 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 04 June 2008 - 04:19 PM

...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.


0

#13 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 07 July 2008 - 11:00 PM

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 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:
#########################################
-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.

 


0

#14 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 07 July 2008 - 11:05 PM

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

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

#15 User is offline   eve 

  • Member
  • PipPip
  • Group: Members
  • Posts: 26
  • Joined: 24-July 06

Posted 08 July 2008 - 12:11 PM

Quote

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?
0

#16 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 08 July 2008 - 03:07 PM

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
0

#17 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 08 July 2008 - 06:59 PM

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
0

#18 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 08 July 2008 - 10:45 PM


Quote

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.






0

#19 User is offline   eve 

  • Member
  • PipPip
  • Group: Members
  • Posts: 26
  • Joined: 24-July 06

Posted 09 July 2008 - 05:16 AM

Quote

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

Quote

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.

0

#20 User is offline   kyt 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 48
  • Joined: 27-March 08

Posted 09 July 2008 - 04:46 PM

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.


0

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

2 User(s) are reading this topic
0 members, 2 guests, 0 anonymous users