I am shipping private JRE along with jar program in the DVD. It takes about 3 minutes if I directly run the program from the DVD. Probably it takes time to load the JRE libraries to main memory as optical disks speed is slow. However when I close the program and re-launch , it gets launched instantaneously as if JRE is installed in the local computer (which is not). I think JRE stays in the memory even after I close the program.
3 minutes is a big waiting time for users, is there any way I can optimize the code (which is the only thing under my control) that it loads only few libraries to launch and load the the other necessary ones on demand. Now probably it is trying to load everything from DVD before showing the program window as suggested by
$java.exe -verbose -jar myProgram.jar
Is there any other solution to launch the program quickly even in the 1st time ? Currently the only workaround is to use the Launch4J .bmp splash screen buts that is very static.
Note: I know installing JRE in local machine will solve the problem but the program is not for technical users, my Launch4J does not find it if installed in custom directory. Also my DVD is copy protected so that the program can not be distributed.
Package your app together with the private JRE into a single EXE that would self-extract into the user's temporary directory and automatically run your app. The startup time improvement will blow you away:
http://www.excelsior-usa.com/blog/excelsior-jet/java-app-as-a-single-exe/
(Download the sample packaged apps and burn them onto a DVD to quickly verify my claim.)
Let me emphasize that you can achieve the result using free tools only, and optionally improve it a bit further with Excelsior JET. Refer to our Knowledge Base article for full instructions (most of which apply whether you use Excelsior JET or not):
HOWTO: Create a single EXE from your Java application
Disclaimer: As you may have already guessed, I work for Excelsior. But again, it all works for the private JRE, and the result, in terms of startup time improvement, is almost as good.
Related
I'm writing an installer for an application. Most of the installer is done and working, but I have on more step outstanding. I need some way to add a setup window to the installer, that will take user input like server address and port, etc. and write these to the relevant files for system start-up. This preferably done through a GUI of sorts inside the installer.
I've tried creating an executable file that runs after installation, but this does not always execute on different systems.
Is there a way to add a GUI to the installer itself that executes after the directory structures and files have been put into place?
Thanks in advance.
In general you should seriously consider doing this as a standalone app that runs when the app first runs and needs configuring. Then it's a program that runs in a user context and can be tested and debugged in the normal way. At least consider what the user is going to do if they want to change the server address or the port - will they need to uninstall your app and reinstall it just to change the server details or the port?
The GUI may not run correctly when started from the install for a number of reasons. It may be initiated with the system account if it's a deferred CA. It wasn't started from the interactive user shell, so it probably won't have any idea of a working directory. It's being run from an msiexec.exe process running in the system directory and maybe with a system account - that's not really the place to be doing your GUI configuration.
I assume you're using WiX, it doesn't say so in your question but it's tagged with WiX.
I would have a read of http://wix.tramontana.co.hu/tutorial/user-interface-revisited (or http://www.dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/ has a relatively easy to read example), you can add or edit any of the dialogue boxes in the installer, you'll need to download the source to get at the built in dialog, and it does require some "play" to get everything quite right but worth it to get a professional looking installer.
I would like to see how everything is handled behind the scenes behind web servers such as apache httpd and tomcat. How does one go about stepping through these applications, making changes, and then viewing changes?? Applications this complex use scripts for building and I presume they take a while to compile, it seems to me that there would be more to it than simply downloading the source code and importing into Eclipse. Or is it actually that simple?
And how do developers who want to work on the code of these projects get around the fact that it will take a fair amount of time to compile these applications (and other non-trivial applications such as web browsers)? When I am working on smaller stuff I am constantly compiling and then debugging. I imagine that is no feasible when it can take several minutes to compile?
Easy: just read.
http://tomcat.apache.org/tomcat-7.0-doc/building.html
Also, http://wiki.apache.org/tomcat/FAQ/Developing
The current Tomcat 7.0.x trunk takes about 17 seconds to build on my MacBook Pro, and that included downloading a few dependencies that I didn't already have laying around. If you want to re-compile a single .java file, you can re-run the entire build and the toolchain (really just Apache Ant) will figure out which files actually need to be recompiled.
You only modified one source file? Only one source file will be re-compiled when you run ant deploy (you don't even need the "deploy": it's the default). If you use Eclipse or some other similar IDE, it will recompile on the fly and you don't need to worry about the command line or any of that.
If you have further questions, please join the Tomcat users' mailing list (or the developers' list) and join the community.
I have a Cocoa application which uses an installer. I want to be able to run code coverage over the code (after it has been installed).
This is not the usual unit-test scenario where a single binary will run a suite of tests. Rather, the tests in question will interact with the UI and the app back-end whilst it is running, so I ideally want to be able to start the application knowing that Gcov is profiling it and then run tests against it.
Any ideas?
Update
Thanks to mustISignUp. To clarify why I asked the question:
The mistake I made was thinking that the object, .gcno and .gcda files had to be installed alongside the binaries (thus making the installer difficult). As it happens, the original location of the files is hard-wired into the code along with the instrumentation code.
The solution I went with is zipping up the code on the build machine and putting it on disk on the test machine. lcov (or just gcov) can be run from there. Alternatively, the .gcda files will be created on disk and they must be copied back up to the machine containing the source code.
Either way, the source code doesn't have to be present at install and run time, but if you want to get your results back lcov-style, the coverage counter files produced must be reconciled with the source code.
The app needs to be compiled with the correct GCC flags which will insert the profiling instructions into the code. It isn't something you can turn on and off. ie your code is modified at compile time to output the coverage info.
So, if you compiled the app with the correct flags it will emit coverage data, if you didn't, it won't (and you certainly wouldn't want it to for an app you were going to distribute).
I need to know how to make a software in Visual Studio(VC++ or VB) that can be run from a USB pendrive?
Is there anyway i can create this standalone software that doesnt need any installation in the PC in which the USB is plugged into?
Just save the executable on the drive. All referenced dlls also need to be stored there. If you have code access active you also need to make sure that the drive is allowed to provide executable code.
One more thought: If the system is linux ore mac then you should consder to switch to Java to be platform independend.
Yes, any native code application can run from a pen drive (so long as any dll's or associated files are also stored with it). .NET apps can also run... if the machine has the necessary run times installed.
I have a Windows CE device that we are deploying, but we have complete control of the software installed on it.
This is not a typical Windows Mobile device, this is a headless device that the user will not interact with. I know that on PDA-style WinCE devices, the .cab file is the preferred application distribution method.
However, on a headless device, we will be writing some type of upgrade/patch server that will ping a server for updates, download them, and auto-install when they are available.
Do I still want a .cab file, or is a .zip (or even something else) better?
What are the requirements for a .cab file - what kind of restrictions / requirements might get in the way and be an annoyance? What are the benefits?
I'd stick with CAB as a package since even headless devices can use the CAB extraction tool. If you ZIP it, then you have to add a ZIP support library and app. CAB also has the ability to add registry entries and define far more disparate target locations than a zip (I want x.dll in \Windows but prog.exe in my program folder - try that with a ZIP).
One thing to keep in mind is that wceload (the CAB extractor) uses a UI by default, so you're going to want to use things like the /noui switch for it.
If you're true headless this may not be an issue (not done that in a long while) but a fairly common "headless" configuration has display support and either the display simply isn't hooked up or is something like a NOP VGAFLAT driver. This allows you to run a shell and have access to all the nice shell APIs, but adds to the challenge that GWES will render dialogs onto the non-existent display.
OpenNETCF also has a CAB Installer SDK that you can use to completely remove any UI with by creating your own installer app. This may or may not be useful depending on the how and when the install happens (through HKLM\Init or otehr for example).