I have created an App using Java which treats excel files using Apache POI. The problem is that when I run the code from eclipse, it works fine, but when I made an executable jar for the app (Using eclipse export executable jar option), the jar is working fine but the results are different, even the size of the produced excel file is different.
I made many research, but I did not find a convenient solution.
Ah yes. I have had that same experience too a few years back.
When creating the runnable .jar in Eclipse, you can choose how .class files from libraries (such as Apache POI in this case) are handled:
Package required classes (.class files) into jar file
Package required libraries (.jar files) into jar file
Copy libraries into a sub-folder
Interestingly, with Apache POI, the three different ways of packing create HUGE differences:
In startup speed
In execution speed
In memory requirements (RAM)
In the resulting output files
I cannot recall which gave me the expected results.
So you have to try them out yourself. (Judging by how Eclipse starts Java projects, it should be #3, libs in subfolder, that gets you the same results). But: try the others anyhow; as I said, HUGE differences ahead.
TBH Apache POI is a 'good' example of how software should NOT be written.
It's awfully bloated and mega RAM hungry and has quite an interesting/odd behavior.
So I wrote my own lib for the newer .xls file format which is just a 100 times faster, smaller and more reliable. And does string caching and cell format operation optimization a lot better. So a 1000000 times better :-P
The upside is that the POI dev team knows the limitations and shortcomings of their project and offers multiple modes of processing files, to overcome said shortcomings. So, after all, kudos to them!
Related
I'm unsure if this would be more suitable for SuperUser, but I figured I'd went with StackOverflow.
Looking at an example of a game developed using Java, Minecraft, we see several resource files in the game's AppData/.minecraft folder. These are files such as .OGG sound files, basically files used to load content into the game, that weren't packed inside the minecraft.jar executable.
I'm working with Eclipse to develop Java applications, and I wonder, since you can import any kind of file into an Eclipse project, which would then be packed into an executable .jar upon export, what are the cons by packing a majority of the items, such as content, text files etc. into the project?
To decrease the size of the .jar?
I'd say, packing more things into a .jar would presume a bit more portability, but would result bit bigger size.
Perhaps my opinion wouldn't follow proper, and if so - why do Java developers want to, if they typically do, leave a lot of files beside the .JAR, for the .JAR to read? Especially static files (files that will not be modified or moved)?
Thank you!
I have been using apache ant to compile my java programs for quite a while, the problem now is that we have to learn to program in the .Net Framework.
I have been struggling with the building process of my csproj in ms build. The requirement we have was to create a build file of a program using only the VisualStudio Command Prompt and notepad++ to create the proj file.
Is there any task in msbuild where i can package my files similar to java jar? I searched within the MsBuild task reference but haven't found anything yet. Any help would be appreciated, thanks!
A JAR file allows Java runtimes to efficiently deploy a set of classes and their associated resources. The elements in a JAR file can be compressed, which, together with the ability to download an entire application in a single request, makes downloading a JAR file much more convenient than separately downloading the many uncompressed files which would form a single Java Application.
When you build a Dotnet application, you usually get a set of files (one .exe and multiple dlls as the simple scenario).
These files being "zipped into one common file" ... that concept does not exist in DotNet.
(except for Silverlight, but that's a different story...that's a "xap" file I believe).
Most people use a Msbuild Task to package their files together.
I use something like this:
MSBuild and creating ZIP files
to zip up my "binaries" on 1 zip file, and zip up my config files in a separate zip file.
That's a "poor man's" method...but it works.
So there is not a direct apples to apples comparison.
..........
That's the simple explanation.
When .dlls reside in the GAC, that's a different ball game.
EDIT::::::::
Here is an example of an extender library to zip files using MSBuild.
How do I zip a folder in MSBuild?
Here is 2 of the most common extension libraries
http://msbuildtasks.tigris.org/
and
http://msbuildextensionpack.codeplex.com/
I have a java program that reads a lot of input data from a database, manipulates it, then writes data back out to another database (using ODBC drivers, excel and access databases, on a new windows 7 machine). The program takes about 17 minutes to run from eclipse, but when I created an executable .jar file it takes an extra 10 minutes to run (27 total).
The two reasons I've found so far for slow jar files (by searching SO and google) is that they're compressed and that it takes a lot longer to write to the command prompt (or error log) than the console in eclipse. I tried creating an uncompressed jar file and it only sped up by about 10 seconds (which could have been completely random, as the run times vary by about 30 seconds anyways). I only have about 10 System.out.println() commands in the program, so that shouldn't be slowing it down much.
Any ideas as to what is causing it to run so much slower, and if there is any way I can speed it up again? Let me know if there are any other detail that may be relevant that I should include. Thanks!
In my case, my application took 3 secs to run on eclipse while it took 2 mins when I run it from jar.
My mistake was to choose "Package required libraries into jar" while exporting my project into runnable jar.
I tried various ways to bring down the time but nothing helped, except..
If you have other maven dependencies or jar files in your project, you should use "**Extract required libraries into generated jar**" while exporting your project into a jar.
This solved my problem in seconds & now both my eclipse & jar file are taking same time to run the application, 2 secs.
Hope this helps the new strugglers.
Regards.
Use JAMon.
It's a monitoring library, that will help you measure execution times of your code.
After you add some monitoring code to your methods, run it in Eclipse and as a JAR file, and compare the results. This should allow you to narrow the search.
Also: Check, whether you are running your JAR file, with the same java version, that the Eclipse uses (for example Java 1.4.x may be much slower than 1.6.x).
I had a similar problem. The shell was running orders of magnitude slower and it had nothing to do with console output. I tried setting JVM memory values but it didn't make any difference
The solution was to package the ANT file with all the JARs into an external folder, using the "Copy required libraries into a sub-folder next to the generated JAR" option in the "Runnable JAR File Export" wizard. Then run the main JAR with a -cp [YOURSUBFOLDER] command line option.
You may check Java VM parameters (like used GC, maximum memory etc). For data-intensive applications GC could slow things down a lot.
Yes I have the same problem.
I have Experimented and got a solution!
just choose "Package required libraries into jar" while making the jar files.
this solution worked fine with me and hope this will also for for you to.
I faced the same issue. The eclipse took 5 seconds to run the application while the jar took 3 minutes. This is due to the way I exported the runnable jar file.
These are mainly two ways to export as a Runnable jar in eclipse.
1). Package required libraries into jar
This will add actual jar files of the libraries into your jar.
This is the cleanest since it separates application class files with
library JARs.
The downside is this makes runnable jar perform very slow.
2). Extract required libraries into generated jar
This way will extract only the actual class files from the libraries
that your application uses and includes in the runnable jar file.
As a result your Jar file will include your application class files
as well as class files of all the libraries used by your application.
This method makes runnable jar perform just like it is run in your
eclipse IDE.
Using this way I was able to run jar application without any lag and
completed just as I run in eclipse IDE taking 5 seconds.
Having said that, best approach would be to use maven build tool. By using Maven it is very easy to maintain and handle third party libraries. You may have a look.
https://www.baeldung.com/executable-jar-with-maven
So, I have an interesting question. I have three people using the same ant build xml file creating a jar file for an Eclipse project that hasn't changed in two months. We each do a build using this xml file and we each get a different sized jar (62 KB, 78 KB, and 101 KB). Also, when I do a winmerge on them, they are dramatically different.
What could cause this difference?
First thing to try: copy them all onto the same computer, unpack them in different directories, and run WinDiff (or whatever) on the uncompressed version. That will make it much more obvious what's going on.
Other possibilities - different versions of Java using different compression levels by default?
In addition to Jon's suggestion, are there user preferences that ant script may pickup?
E.g. build.properties file that can live in project directory, user home directory, etc.
It may be the case that there are different customizations of the project on each person's workstation.
The only difference I can see can be:
Difference in environment variables resulting in difference in compilers. Does your ant script use any other utility in addition to the regular javac for compilation or packaging? Ex: does it use AspectJ or some other assembling utility? Is that dependent on environmental variables that are different for different machines?
Difference in the size of dependent jars (one of you might have commons-logging-1.8 while the other may have a different version for example)
Do you invoke any other build utility from ant that does dependency management such as ivy for instance?
You said winmerge shows dramatic differences. Are these w.r.t. the size of the various components inside the jar or are there structural differences (folder structures, different files etc.)? The latter would be more perplexing for sure.
Sounds like the folders being jarred together are not empty when the process begins.
I have recently learnt how to program in java, I was looking at some open source programs from sourceforge.net and after downloading these programs I don't understand the file structure most of the programs follow. Pretty much every program has src,bin,lib etc folders, how do I know the standard way of organizing my program. Is there any book or resource which explains this? also how do I compile this source code once I have downloaded it, to make a jar file from it
thanks
src is (usually) what it sounds like: source code
bin is (usually) shell scripts related to the product
lib is (usually) external dependencies needed for compilation
Most projects document how they build: look for a README or grok the project website. These days for a Java-centric project I would expect Ant or Maven.
What you have downloaded is actually a distribution version of the program. The directories as listed by carej are kind of a convention, mainly derived from how things are usually done on a Unix system.
Most projects supply some manual on how to build. This can be tricky if not all libraries (jars) used by the program are supplied in the distribution. Some of the Apache Commons project do it like this, thus forcing the user to download dependencies seperately.
If you just want to use the program try to find a binary version. This will usually consist of jars, scripts and documentation. Source distributions are useful if you want to look at the source and/or make modifications.