Jump to content
Excelsior Forums
Sign in to follow this  
MartinP

Single EXE

Recommended Posts

Hello,

I've compiled my application with the Global optimizer set on, but the exe still needs some java-API dll-s. How to get linked them statically into the exe, too?

I know that my application shouldn't need dynamical loading of classes, but without the jvm.dll, java.dll and hpi.dll it doesn't run.

I'm confused by the documentation, because at one place there is written:

"Global Optimizer detects the platform classes that are actually used by the application and compiles them along with the application's classes into a single executable."

but at another place:

"Excelsior JET is not able to create a single all-inclusive executable that can be deployed to target machines by simply copying."

Which is true?

Share this post


Link to post
Share on other sites
Which is true?

Both.

Java *classes* (.class files) can be compiled into a single executable.

You missed Java native methods which are typically written in C/C++,  placed into a few DLLs and should be deployed "as is".

"Excelsior JET is not able to create a single all-inclusive executable that can be deployed to target machines by simply copying."

Nevertheless, (if your primary goal is to simplify deployment) you can create a self-contained directory so that the application can be installed on target  systems by a simple copy operation

Share this post


Link to post
Share on other sites

Thank you for your answer. Thus it should not be difficult to provide the C++ implementation in the .obj form, and link them to the .exe too ;-). We look forward to it :-).

Share this post


Link to post
Share on other sites
Thus it should not be difficult to provide the C++ implementation in the .obj form, and link them to the .exe too ;-).

It's not so easy because lots of code use namely run-time dynamic linking (looking for a dll and loading it at run time).

Note also that JRE includes many resource files that are used by the standard Java classes (and by the native methods) through file open/read/close operations.

Placing them into a single executable would require substantial modifications.

We look forward to it :-).

This feature is not on our todo list for next releases. If you are *really* looking to it, you may place a PO for custom engineering.

B)

Share this post


Link to post
Share on other sites

I don't want to argue, you are surelly more an expert in this area than me. But resources are looked for in classpath, so it seems to me that it would be sufficient to search the exe too - which surely must be performed already.

It's not so easy because lots of code use namely run-time dynamic linking (looking for a dll and loading it at run time).

Do you mean lots of JET code, or lots of java code?

Share this post


Link to post
Share on other sites
I don't want to argue, you are surelly more an expert in this area than me. But resources are looked for in classpath, so it seems to me that it would be sufficient to search the exe too - which surely must be performed already.

Quick question: are the fonts that come with JRE looked for in classpath?

B)

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

Do you mean lots of JET code, or lots of java code?

I meant the implementation of Java platform classes and native methods.

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

Again, as a Java licensee we have a legal way to change it. But it will take time and manpower.

What's your main purpose of having a single EXE? If, for some reasons, you do not like installers, why does not self-contained directory without deployment dependencies match your requirements?

Share this post


Link to post
Share on other sites
Quick question: are the fonts that come with JRE looked for in classpath?

Well, OK. :-)

What's your main purpose of having a single EXE? If, for some reasons, you do not like installers, why does not self-contained directory without deployment dependencies match your requirements?

Because the full RT directory has about 20MB. And as I need only part of it, I do want to cut off the rest. Though the compiler knows which DLLs I need, it's me who must to determine and delete the superficious RT DLLs, by hand.

Share this post


Link to post
Share on other sites
Because the full RT directory has about 20MB. And as I need only part of it, I do want to cut off the rest. Though the compiler knows which DLLs I need, it's me who must to determine and delete the superficious RT DLLs, by hand.

You may easily do that in a safe manner using the bundled JetPackII tool.

Check the "Java Runtime Slim-Down" chapter of the JET User's Guide.

    http://www.excelsior-usa.com/doc/jet500/jetw.html

Share this post


Link to post
Share on other sites

Thank you, I didn't notice those green and red squares in the "Deatched components" dialog. This would solve the issue. However I wasn't able to test it, as the trial version of JET expired, 5 days after installing it. I filled a bug.

Share this post


Link to post
Share on other sites

Hello,

I'm returning :-).

Check the "Java Runtime Slim-Down" chapter of the JET User's Guide.

I've tried it, and it works - to some extend. When detaching all JavaSE components, the RT directory "slims-down" from 20MB to 6MB, good. But by hand I'm able to cut the RT directory down to 100kB which is even better :-). (It's an extreme example.)

What contains the automatically reduced RT directory in addition to what I left there myself? Probably files necessary for downloading the .pkl file from the internet (there are some net, pkcs, dns etc files). But I knew at the beginning, and could tell to the packager, that the application doesn't need any extra files to download. Thus if there was a checkbox denoting that the application is "standalone", more garbage could be omitted from the RT directory.

Share this post


Link to post
Share on other sites
I'm returning :-).

I see.  B)

the RT directory "slims-down" from 20MB to 6MB, good.

The question is the size of installer while disk footprint is less of an issue. Did you try to create an Excelsior Installer setup for the project?

But I knew at the beginning, and could tell to the packager, that the application doesn't need any extra files to download. Thus if there was a checkbox denoting that the application is "standalone", more garbage could be omitted from the RT directory.

Then you app may stop working on enduser computers. After nightmare debugging you reveal that some class specific for timezone support / localization / particular h/w / screen resolution and the like is missing.

We saw all this mess about 4 years ago, when there was such an option in Excelsior JET and people tried to use it.  No, thanks.

The currently implemented technique is a good trade-off between reliability and download size figures, if the purpose is pragmatic deployment of Java apps rather than investigating theoretical bounds.

B)

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
Sign in to follow this  

×