I've been debating whether or not to bundle a JRE with my application. I've listed some reasons below why I think it would be useful, but I'm also hesitant to do this because it makes the app much larger.
Why I think it would be useful:
Right now the app is run by running a batch file (well, a shortcut to a batch file, it is run via a batch file). It just calls java -jar XXX, which requires Java to be in the path, which is not always the case.
We're a small team and not fully running on Java 7 (there are some strange errors we are trying to debug still). If a user has Java 7, they may have an unpleasant software experience - this is not good for us. Packaging a specific version of the JRE ensure we've fully tested on it.
We support 32 and 64 bit Windows platforms. When the user downloads the software, they choose 32 or 64-bit, but this is asking which version of Java are they using. Most users don't know if 32-bit java is installed on their 64-bit platform, and it can be confusing to download 32-bit even though their OS is 64-bit.
There are some good reasons why not to package it though:
If a security hole is in Java or other significant updates are made to the JRE, we need to distribute a new version of our app with a new Java version. We are generally updating our app every couple of weeks, so I'm not too concerned about this one right now.
The app will now be much larger because it includes a packaged JRE.
Can anyone provide some guidance as to whether or not (based on these requirements) they think it is a good idea to package the JRE? If not, what are some alternatives to just hoping that java is in the path (and more importantly if it's not, it is possible our users may not know how to add it).
Java Web Start. The JRE will be on the path.
For version control, see Java Web Start - Runtime Versioning & particularly Earlier Version.
JWS can partition resources between a 64 bit & 32 bit JRE.
So, 'bad idea to bundle JRE'. Use web-start instead.
I would suggest to NOT bundle the JRE although I often see it as a common practice.
Instead I would either use webstart (can be used offline as well) or some other installer or pacakge manager solution that ensures that Java is installed including the correct version. This will widely depend on the operating system you expect to run on.
Going down the way of including Java begs the question what else you want to include, just to be sure... which will lead you to the whole operating system and everything needed thought to the end.
I would also suggest to closely look into what types of users will install the app and adapt to that and make some sort of estimate on how capable they will be.
Related
For reasons related to customers with different applications versions i need to maintain in my laptop several versions of Delphi (7, XE 7, XE 8, XE 10.1 Berlin and XE 10.2 Tokyo). My main concern is about PATH variable and problems during compilation and linking time. There'll be any problems ? Do i need to change what ? Any suggestion is most welcome.
I have all versions of Delphi from 7 thru XE8 installed in a single VM and versions 1 thru 6 in another (my Delphi "museum" :)).
The Delphi "museum" is a Windows XP VM to avoid the problems that those older versions of Delphi have with more recent Windows versions. The Delphi 7+ VM started life as Windows 7 VM but has since been upgraded to Windows 8.x and then Windows 10 without any problem.
The two sets of VM's are kept separate in this way to avoid OS complications with those older versions and because I use 1-6 only very, very rarely and version 7+ more often. The precise version at which the "cut-off" was made was determined by the fact that dotted unit names were also only supported from version 7 onward so a lot of the code I ever wrote for 7+ is simply not even usable with 1-6 so there's no point having them alongside each other.
In both cases the IDE/compilers (any version) have no intrinsic problems running alongside other versions.
The only real difficulty is installing Delphi 2006 on Windows Vista (or later). Should you ever need to, this is the only one that presents any real difficulty due to a dependency on .NET which is not handled very well by the installer. But it is do-able and not especially difficult as long as you follow the steps described in detail by Dr. Bob.
Install Locations: Minimising PATH Length/Manageability
With a large number of Delphi versions installed the overall length of the PATH variable can become a problem, but in my experience this is a problem only of manageability. To simplify things on that score and to avoid problems with earlier versions of Delphi on more recent versions of Windows, I installed all my IDE's in a sub-folder directly off the root:
c:\delphi\<version>
Where version is each Delphi version number (e.g. 7.0, 2007, 2009, XE, XE2 etc etc). I then have a number of other folders for shared components:
c:\delphi\bde
c:\delphi\database desktop
c:\delphi\shared files
When I setup the VM I installed each Delphi version in order and changed the installation locations for these components to these locations. In this way there is one common installation of these shared components which is updated by each more recent version as required.
I also have a c:\delphi\common\ folder where I keep things such as pre-compiled FastMM_FullDebugMode.dll etc to be shared across all Delphi versions.
I did all this primarily for my own benefit however, to keep things organised and consistent rather than to solve any particular problem (apart from the previously mentioned issues affecting older versions if installed under Program Files).
e.g. if you simply install into default locations then you will end up with versions "scattered" across Borland, CodeGear and Embarcadero folders. All my IDE versions are in one place.
With or without these considerations, the IDE should be perfectly happy to run all the different versions you mention without any particular configuration required, but you may need to pay attention to configuration/assumptions made by some 3rd party packages/libraries.
3rd Party Packages
Most 3rd party libraries/packages are usually fine, but there may be the occasional one that needs a bit of help. I myself have never come across anything that couldn't be resolved but have to say that I also don't use 3rd party libraries particularly extensively so simply may not have come across any "trouble makers".
In any event, it's unfortunately difficult to give general advice on this point since it obviously depends very much on the 3rd party libraries and the particular "problems" that any particular one might have.
I have all Delphi versions from 6 to 10.2 installed on a computer running Windows 8.1 64 bit. It's not easy to setup, especially for the older versions. The first rule would be: Do not install to "c:\program files", use a separate directory (I use "c:\delphi" with a numerical subdirectory for each version.)
That has two effects:
Older versions, that still write to the installation directory, will work.
The path entries will not be as long (even though, they will be too long after the 5th or 6th Delphi install, see the comments to your question for possible solutions)
Why did I not use multiple VMs? I maintain GExperts for the versions mentioned above and it is too much hassle to maintain the VMs. As long as it works, I will keep all Delphi versions on my computer. If it stops working, I will probably drop GExperts suppport for some Delphi versions.
There are multiple articles on getting older Delphi versions to work on Windows 8.1. They might be useful if you try it.
They are all in the category Windows 8.1:
https://blog.dummzeuch.de/category/windows/windows-8-1/
In Wheezy there is a source package for gcc-3.3 which only builds libstdc++5. Close examination shows that building of debian/control (from control.m4) can be modified so that the full package is built, which is my goal (legacy project, needs to be built with libstdc++5-dev:i386 and so on, but I want to build it on Wheezy64).
The question: how do I (find what to) tell dpkg-buildpackage to enable building the rest of the package? Should I just download the source package from archival Lenny?
Impossible at all?
Thanks in advance for any directions.
yes, well.
the preferred way would be to port your legacy project to build with a current g++ (4.8).
this would allow your project to run on any wheezy system (and hopefully on futgure systems like jessie/...)
if this is not an option, you should first try to download the source package from your target release (wheezy), modify debian/control to build all the packages you need, and build them.
chances are high, that gcc-3.3 and friends are disabled only to guarantee that nobody uses obsolete software anymore (so debian people don't have to worry about maintaining gcc-0.1 through 6.66).
as a last ressort you could try to get the source package from lenny and build that.
chances are high that this will be quite complilcated, and bug-ridden.
if youplan using your legacy project in two years from now, you might be better of stating to port it to recent ilbraries now.
I recently had to do something like this. What I did was install an old (32-bit) distro as a VM guest (which included gcc-3.4) just to make sure that it built and worked in "the past" before making changes for current build tools.
I did this mainly because you can be pretty sure that the build tools and environment worked back then, because everyone needed them. Not as many people are going to be using old tools now, so it's less clear that things will work. But it could work alright.
It's not exactly clear from your question whether you want a 64 bit or 32 bit version of this legacy software. If you want a 64 bit version, there might be fewer issues to port first to a modern 32 bit environment, then a modern 64 bit environment. At least you'll be able to identify where the bugs are.
My question is similar to the one asked in this forum in 2010 - "is JRE installed in Windows & Linux?". And I am wondering if things have changed since then
In particular, my site hosts a downloadable Java application that basically transmits specific files from the user's PC to our server. But every now and then I find that some of my users - all non-techies - don't have JRE installed. And hence, I have to ask them to install JRE first.
Asking users to download something before they can start using my application can only ruin the end user experience. Understandably, that is a no-no. And so, I am ready to re-implement the application. But before I can propose re-implementing the app in some other technology - like Qt - I need facts to make a case. In particular, I would like to know
Is it safe to assume that any PC with an OS that is XP or above would have JRE installed on it?
Is Qt a viable - and preferable - option for making a "download-now-use-now" type of application? Don't Qt applications need a JRE equivalent too?
Are Qt applications able to update themselves like Java apps can?
Other than having to maintain/compile multiple versions of Qt, are there any other disadvantages to using Qt?
Thanks for your responses
Abhinav
No, it is still not safe to assume that every machine had the JRE installed, though it is easy to install for every machine.from the Java website. Java is not installed by default on any Windows computer but I believe it is installed by default in many Linux distributions.
Qt is a GUI front end system for other programming languages. I know of Qt implementations for C, Python and now Java. If you are intending to use Java Qt then you will need to use the JRE to run it, it is not a way to get around restrictions of Java but is instead a way to make applications look consistent even though they are written in different languages.
A Java Qt application will have the same abilities as a normal Java application in terms of updating.
Starting with the next version of Mac OS X, Java will no longer be included in the system and I don't want to force my customers to install it themselves. So I would like to do what I do on Windows - bundle it with my app. It also gives me some hope that it could get included in the Mac App Store.
Where can I download a Mac OS X JRE that I could include with my application? Or can I just copy the one that's installed on my Mac?
Update (4/15/2013):
As Thorbjørn helpfully pointed out, Oracle now has a solution for this. See http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html. However, I'm keeping the original content for "historical purposes", and because it was a fun research project.
Previous version (with edits):
This is a great question. I was going to respond that you are simply ahead of your time -- as you pointed out, Java is not going to be removed until the Lion release. However, this article makes it clear that using Java today is not allowed:
Apps that use deprecated or optionally installed technologies (e.g., Java, [PowerPC code requiring] Rosetta) will be rejected.
At the same time, no one has announced a redistributable JRE for Mac OS X yet. I think your best bet, bearing in mind that you are forging new ground, is to check out the Mac OS X Port wiki page of the OpenJDK project. It does describe how to compile your own JDK, but it does not clearly state whether or not the resulting JDK can be "bundled" cleanly or not. I think you will have to try it and see :-(.
Also, it's not clear if the OpenJDK licensing allows this at all (IANAL). Hopefully someone else has already figured this out with regard to Linux/Windows, although of course the rules may be different for the Apple contributions.
Hope this helps. If nothing else, it's a starting point.
EDIT: I am going to throw out one additional suggestion. We now know that Mono apps can be packaged for the App Store. Furthermore, IKVM.NET is a complete implementation of Java that runs on top of Mono. You could try, in theory, to put these two pieces together and get a Java app, bundled for the App Store, that does not in fact require a JRE!
If you try this, I would love to hear how it works out :-).
EDIT 2: Unfortunately, the App Store and the GPL do not appear to be compatible (see http://www.zdnet.com/blog/open-source/no-gpl-apps-for-apples-app-store/8046). The OpenJDK license isn't exactly the same as the GPL, but it's pretty close (again, IANAL). Therefore, Mono & IKVM.NET may be your best bet. Good luck!
In the same web search that I found this question, I've found the these instructions from the OpenJDK project. Not having tried them myself, I cannot comment on how well they work.
Meanwhile, another, very detailled article was published by Marco Dinacci which also goes into signing and sandboxing.
Apple has joined the Sun/Oracle OpenJDK open source project last month, so Java on Apple is alive and kicking.
Just tell the user to download and install the OpenJDK JRE for Mac OSX (when it becomes available, right now it´s just source code).
And no. you cannot include "the folder that is in your mac" without permission as it is copyrighted code from Apple.
Finally, packaging a "private JRE" is a very bad practice, it will make your app bloated, andif the user ends up running several Java apps, he will end up running multiple Java VMs simultaneously which is a terrible waste of system resources.
I've written an application using gtkmm and libpcap under Linux. Of course, gtkmm depends on GTK+.
After porting it to Windows and attempting to distribute it, the feedback I received is that there are too many dependencies to install.
The user has to run installers for the GTK+, gtkmm, and winpcap runtimes before they can run my little application, which admittedly is a pain.
GIMP for Windows seems to use an installer that launches a GTK+ installer if needed, but doing that for three different libraries seems a little excessive, especially in terms of the installer size.
Is there a better way to distribute this? I believe winpcap actually has to install a service, so it probably has to run the installer, but maybe I could bundle the GTK+/gtkmm libraries in the runtime folder?
I'm quite a bit more familiar with Linux development, so I'm not sure what the best course of action is.
I highly recommend using a tool like Advanced Installer to deal with this for you. Making a proper installer on windows is a real headache, so it's well worth your time to use a GUI tool to help you out. AI (and other installers, for that matter) can install and manage windows services, prerequisites, and so on, and in the long run you'll save a lot of time by using a tool like this to help with your deployment. Advanced Installer in particular has very good support for managing different dependencies, along with their associated versions, and it can also install a native Windows service during the install process. They have a freeware version, but depending on the nature of your product, you might want to spring for one of the commercial versions.
Basically, if you're serious about deploying on Windows, you should invest the time (and money, possibly) to make a proper MSI-style installer. Not to knock the NSIS crowd, but making non-standard Windows installers always results in a lot more work for the developer, and a more uncomfortable experience for the end user.
If you want to manually package the GTKmm runtime, see this link at gnome.org for more details (look under Redistributing). You can also silently run the GTKmm installer using the /S flag.