Related
I want to make a Mac Application using Java code I wrote, and I want to make it that the person using it doesn't require Java to be installed on their own computer.
Is there a way to create a Mac Application so it can run on any mac, whether they have Java installed or not?
Either bundle a JVM or compile native
You have a choice of three ways to deliver a local Java-based app to a Mac user.
User installs a JDK or JRE on their machine. (Or I.T. sysadmin person does so.)
App comes bundled with a JVM for a specific OS and specific chip architecture.
App is compiled to native code for a specific OS and specific chip architecture.
Install JDK/JRE
In a controlled environment such as a corporation or school, it may be practical to install a JDK or JRE on every Mac. If you are writing JavaFX apps, you could install an edition of a JDK/JRE that comes with the OpenJFX libraries.
Your Java app can then execute by using the already-installed JVM.
By the way, in such a controlled environment, OpenWebStart is a way to deliver and launch a local Java app by using the convenience of a web browser.
In contrast, Oracle has abandoned the approach of expecting common consumer machines to come equipped with Java pre-installed. For details, see the Oracle white paper, Java Client Roadmap Update. So expecting individuals to have Java installed is not practical.
Bundle JDK/JRE
You can build your app in such a way as to include a JDK/JRE for a specific kind of machine, meaning a specific operating system and a specific chip architecture.
For Macs, that means you need one build for Macs with Intel (x86) chips, and another build for Macs with Apple Silicon (ARM, AArch64) chips. You would need to to either supply two separate versions of your app, one for each child, or perhaps a “fat binary” that includes two JDKs/JREs for both chips. The fat binary approach was supported by Apple (and its originator, NeXT Inc.) in previous chip transitions, but I’ve not verified is this is the case now in the Intel to Apple Silicon transition.
Modern tooling helps with embedding a JDK/JRE. See jlink and jpackage. See Packaging Tool User's Guide. As of Java 9, the Java Platform Module System enables including only the parts of the JDK/JRE actually used by your particular app. Unused parts are omitted, making for a smaller-sized final app artifact.
Compile native
The last way uses GraalVM technology to compile your code to native code specific to the targeted runtime machine. Instead of compiling to bytecode for a conventional JVM to interpret and optionally JIT-compile at runtime, full compilation to native machine language is performed when you build your app. This approach is cutting-edge, perhaps bleeding-edge. So research carefully and test thoroughly if you dare to consider this novel approach.
With both of the last two approaches, you have the option of distributing through the Apple App Store.
You don't need JDK to install on the client machine but as we know java converts the program into bytecode and a java compiler is needed to compile that bytecode into machine language you must install JRE on the client computer whether it is mac or windows or any other operating system
As far as I know, I can run .mex files on Linux that were generated on Windows by installing Matlab Runtime on Linux (correct me if I am wrong). But what if I want to use a MATLAB generated java package, that was generated on Windows, on a Linux (like Ubuntu)?
Objective:
I have to test a feature that uses audio processing. If test is successful, we will buy the products we need. At the moment I have my requested license on Windows, since the requested license have machine specific limitation, I am able to generate some test java code on my Windows machine, now the application is to be deployed on android, so I learnt from google that it needs matlab runtime to run or compiler to use converted/generated code. Android system has no MCR or simple Matlab Runtime installation support, so I moved to this solution.
Use a linux to host servlet that takes some input from android, do processing return answer in terms of json or text. Now my java package is generated using Windows machine, and I am lost.
From my knowledge this code-convert-servlet-deploy-once approach is cost effective than MATLAB Production Server, since we have to buy license once for the specific products. Remember licensing phase is after we test if this approach is giving us desired results.
Specs:
Windows 10
MATLAB 2016a (Trial)
MATLAB products (Compiler/sdk, Signal Processing/Audio Processing Toolbox)
Package made using JDK 1.7.x (Exactly matching MATLAB jdk/jre version on Windows)
Ubuntu 16 Desktop (with Oracle jdk 8_101 installed, also MATLAB Runtime installed, I can also work with jdk 7.x (same as MATLAB used on Windows when generating package))
Questions:
How can I use this java package in Linux when I create a java program?
What software + licenses are needed to make it possible?
Should I install MATLAB ON Linux machine, generate Java Package ON Linux machine and use that package in java program ON same linux machine? ( I think I will need to request license for it again )
Are there any other methods? Am I missing something?
Java packages generated by MATLAB Compiler SDK are in general cross-platform - however, they may call mex files, or other libraries, that are platform-specific, and if they do the Java package as a whole will end up being platform-specific.
You aren't entirely clear about whether you're calling mex files or not; and you may be calling platform-specific libraries without realising it (for example, Signal Processing Toolbox might call out to some library for some of its operations).
In addition, your comment about being "able to run mex files on Linux that were generated on Windows by installing the MATLAB Runtime on Linux" is confused - mex files are not cross-platform, and the don't use MATLAB Runtime at all.
So with respect to platforms - you may be able to use a Java package generated on Windows on Linux, so long as it doesn't call any Windows-specific mex files or libraries. But if you generate it on Linux, you can rule that issue out, so it will be easier for you if you use the same platform for compilation and execution. It should be fairly easy for you to reassign your MATLAB license to a Linux machine to do that.
Am I missing something?
Yes: the way you're proposing to do things is very unlikely to scale well. If you have a Java servlet on your Linux server along with a Java package generated by MATLAB Compiler SDK, then whenever you make a call to the servlet it will make a call to the Java package, which will start up the MATLAB Compiler Runtime (MCR), run your MATLAB code, return the answer to the servlet, and then shut down the MCR.
The MCR takes quite a long time to start up (nearly as long as MATLAB). So each call will take rather a long time, just due to MCR startup times.
So you can get around that by creating some sort of utility tool that will start up a an MCR and keep it there, and pass through requests and return answers to the servlet.
But then you've only got one MCR - what happens if you get multiple requests at once? They'll be queued up (or dropped) and it won't scale. So you'll need to improve your utility tool, so that it manages a pool of MCRs and passes requests through to a free one, load-balancing them as it goes.
But then what happens if an MCR crashes, or runs ouot of memory? The utility tool will need to monitor that possibility, and restart any crashed ones.
And you'll need some extra stuff that will enable you to administer all that stuff conveniently.
Once you've done all that (which will be hard), you'll realise that you have now pretty much written MATLAB Production Server. I know it's expensive, but you might like to take another look at it before committing to the solution you're considering.
I want to develop a cross platform application.
Is Java cross platform? I mean, can I develop a Java application in Windows and use it in Mac OS X and Linux?
If yes, how?
I find application written in Java, has two setup file one for Windows and other for Mac. This confuses me.
Any illustration or suggestion will be highly appreciated.
Is Java a cross platform?
Java is cross platform in the sense that a compiled Java program runs on all platforms for which there exists a JVM. (This holds for all major operating systems, including Windows, Mac OS and Linux.)
I mean I can develop Java application in windows and use it in mac and Linux?
Yes, this is possible.
This (and the security aspect) is one of the main advantages of running the programs in a virtual machine.
If yes how?
Write your application in Java (In .java files)
Compile your application using Eclipse or javac (into .class files)
(Optionally) Bundle your .class files in an executable (.jar file)
The very same .jar file can be distributed and executed on Windows systems, Mac systems, etc.
I find application written in Java, has two setup file one for windows and other for mac. This confuses me.
This is because some applications rely on platform-specific features. They are then bundled with different platform-specific libraries.
Unless you're developing an application that itself relies on platform-specific features, (such as for instance low-level system calls), you should be able to do just fine with ordinary Java.
Important comment by #Peter Lawrey:
It can be while the application is platform independent, the setup program is not. e.g. IntelliJ has three platform specific installers which are not written in Java, but have a zip which you can just unzip on any platform and it will work.
You can run Java applications on every device that has a JVM. If it does not, you're out of luck.
The comment from Oded is important. C and C++ have compilers on lots of devices.
Java byte code won't need to be recompiled when you switch platforms.
C and C++ will require that the developer recompile the application before distributing it to the target system, but once that's done clients will be able to run without an issue.
The problem of platform-specific customizations and settings has to be dealt with no matter which language you choose. The more your application depends on platform-specific features, the less portable it will be.
UPDATE:
Let's revisit the original words in the question:
I want to develop a cross platform application.
Here's the objective - a direct quote. No details about web, mobile, or desktop app.
Is Java cross platform? I mean, can I
develop a Java application in Windows
and use it in Mac OS X and Linux?
Define "cross platform". Sounds like the bias here is "byte code portability". C/C++ can't do that, but "source code portability" is certainly possible as long as you stick to ANSI C/C++ and refrain from using vendor extensions.
Java's claim to fame from the beginning has always been byte code portability. That's what the JVM gets you. That does not mean your whole application will be portable, because you might not have managed other dependencies well.
If I substitute "C/C++" for "Java in that bloc, then cross platform means something different. I cannot pick up a .exe or .so compiled for one platform and expect to run it on another, but if I create an .exe or .so for each platform and make them available it's certainly possible to make the same source code runnable on multiple platforms.
If yes, how?
If you have packaged your Java app as a JAR, you can put that on any platform you like.
If you have multiple C/C++ .exes for the platforms you're interested in, you can certainly run it when you need to.
There is an important caveat with regard to Java portability. "Business logic" (non-UI stuff) is quite portable, but there are at least a half-dozen different (and incompatible) user interface paradigms for Java, so, eg, Java code written to run on an Android (even ignoring Android's incompatible JVM) won't run on a Nokia phone, and code for either one will not run on a desktop PC.
But there's no other language that does better, to my knowledge.
Yes, Java written and compiled on one OS can run on another OS. There are JVMs available for many modern operating systems.
Java apps are packaged as .jar files. These can run on any operating system that implements the correct Java Runtime Environment for the application, provided the user has installed that JRE (JREs are provided to users for free).
The precise procedure for running the app is different for each operating system.
The Java Development Kit provides libraries that allow system functions (e.g. file operations, user interfaces) to be invoked that ought to work on any OS. However the precise behavior may vary (in a similar way to how a website can look different in different browsers). Also, Java apps may have a 'look and feel' that does not precisely match the look and feel of applications designed specifically for that OS.
It depends what you mean by "cross-platform". Java code can be compiled to byte-code binary class or jar files on any OS supporting the JDK and run on any platform supported the JRE. However, most compiled languages can be compiled on any platform provided the designers has catered for it. Java is more easily portable than, say, C++, but that doesn't mean C++ code won't be able to compile on any platform.
In other words - don't choose your language on this single feature alone. Choosing the best language for your application would be a better way of going about it. Perhaps a scripting language would be best for you. Maybe post another question asking what language to use to solve your specific problem.
I wrote a little game in Java with sound.
I've used standard library (AudioInputStream and Clip classes).
The program works very good with Windows XP, BUT I haven't got the sounds with Windows Seven or Linux Ubuntu.
Java 6 was installed for all those OS, and I've compiled the program with the standard compiler JAVAC.
So Java is not so "cross platform".
JAVA is not really cross-platform because is just a design, some JAVA implementations can be cross-platform but it really depends on the JAVA implementer.
SUN/Oracle makes the JAVA standard implementation for Windows, MAC and Linux and if you build programs with their JDK you should run the programs with their JRE, if you try to run it with other JRE there might be compatibility issues.
This can be seen more in the mobile, some phone makers won't make a full implementation of JAVA because hardware limitations or because they want to control the device's software, they carry the JAVA logo but you must use their own JDK and those programs could not run outside of their JVM implementation.
Another issue with JAVA is that some functionality could be deprecated and what ran in some specific version of the JRE could not run in newer versions or run in a different way.
The big problem is when we are talking about mobile apps. For desktops OS, java can run perfectly, but for mobile devices, developers can, practically, only create for Android. There are tools like Totalcross that helps java developers to create apps to iOS and Android. The focus is maintain the WORA assumption to every platform, even mobile.
I am Java developer who is using Eclipse on a X86 computer to code. I am considering to buy for other reasons an Desktop Mac computer and I would like to use this computer to do my coding work. I know there is a Eclipse version for Macs, I am asking if there may be some problems/issues related to Macintosh computers. Thanks!
It really depends what you'll be doing.
In terms of the IDE, it will work just fine and you can copy your files/projects over and they will "just work".
However, there are some things you need to be weary of:
Key mappings might be different
You won't be able to do any JavaME programming as there is no Mac toolkit for that.
If you're doing Swing development, make sure you test your code on your target environment as things might look different.
Other than that, Macs work fantastic for Java coding.
No, Eclipse works just as well on a Mac as on a Windows or Linux computer. Key bindings are different though; if you're used to the shortcut keys of Eclipse on Windows, you'll need to get used to different shortcuts on the Mac.
Apple just announced that they are deprecating their Java platform. That may cause some problems in the future. Update: however, I have seen that Eclipse works with the soylatte OpenJDK port.
http://developer.apple.com/tools/eclipse.html
and if you want the non-Apple-bs experience:
http://cdtdoug.blogspot.com/2010/04/mac-gets-no-love.html
From my personal experience, Eclipse actually works better on OS X and Linux than it does on Windows. I'm a professional plugins developer and I do all my coding on Mac. I blog about Eclipse and Mac related topics, so I invite to read it.
Adding to the limitations mentioned in other answers, if you have specific plugins that you need, not all support Macs, although most. For example, The Eclipse TPTP (short for profiler) project doesn’t profile on Mac. There are alternatives in most cases, though (AFAIK, not free in the case of TPTP).
Personal experience for RCP-development: 2G of RAM are not enough (at least not for our project), so the current MacBook Airs are not suitable at all for development. But then, you're talking about desktop Macs anyway, so if you can get the >2G, it should be fine.
During the 64bit transition phase, there were some glitches with missing 64bit Cocoa, but that has been resolved. Some of the extensions may be platform specific: currently, TPTP (Test and Performance Tools Platform Project) still has some limitation.
eclipse for mac works exactly as you know it from your pc. the only thing that differs is the arrangement of some keys (the # is on L, the arrangement of the braces differs a bit)
Eclipse works fine, but with different keybindings.
I have found that sharing files with other computers - e.g. through a source repository - may give you character set conversion issues. If you stay with pure ASCII in your source you should not have any problems.
You can download Eclipse 3.6.1 from eclipse.org directly (where your platform is autodetected) or from http://download.eclipse.org/eclipse/downloads/drops/R-3.6.1-201009090800/index.php#EclipseSDK
I would suggest getting the Java EE version from the frontpage. It contains web stuff I use regularily.
Which (commercial or free) installer tool would you recommend to replace InstallAnywhere as the installer for a Java EE application? What do you specifically like about it, and what are its downsides?
Some requirements:
Must support running custom Java code as part of installation procedure
Must support Windows, including latest 64-bit versions like Windows Server 2008; support for other target operating systems is a plus
Must be able to install a bundled application server (such as Resin or Tomcat) as a service on Windows
Must support basic stuff like copying and moving files around, editing configuration files, extracting ZIPs, etc.
(Must support bundling a specific version of JRE; at the very least by including a ZIP to be extracted)
Edit: a few more points:
Preferably does not depend on a preinstalled JRE (or any other 3rd party runtime environment or library) on target machine; in other words, can produce an independent Windows .exe (or .msi)
The tool should preferably be cross-platform so that installer development can be done on Linux, Windows, or Mac.
Should preferably have a decent GUI for putting the installer together. Once that is done, however, it must be possible to skip the GUI and make installer building part of automated build process.
In this case, unfortunately, SO didn't tell us much that we didn't know already (and indeed the tool we ultimately chose was not mentioned in any answer). However, I'm posting our experiences here, as they might be helpful to others later on.
We (quickly) evaluated the following installer tools, mostly by looking at their websites and browsing for other information on the web: Actual Installer, Advanced Installer, BitRock InstallBuilder, Inno Setup, Install Creator, Installer VISE for Windows, InstallShield, install4j, IzPack, NSIS, openInstaller, Scriptlogic MSI Studio, Smart Install Maker, Symantec Wise Installation Studio, and WiX.
We screened out most of them early on, and ended up shortlisting two options for closer evaluation: BitRock InstallBuilder and install4j. For these tools, we downloaded evaluation versions and did some prototyping, to see if the things that are most important to us are really supported, and how easy or hard it is to get things working.
Both of the options were good in many things (and both seemed good alternatives to InstallAnywhere):
They produce completely native and pretty Windows .exe installers that are
easy to customise with your own graphics etc.
Both tools could easily be automated so that installer building is triggered from Ant. (With install4j it literally took me just five minutes to learn it and then implement it.)
Both companies seem to have good support (well, at least for prospects evaluating their products ;-) Especially from BitRock we got very quick replies.
In the following things install4j seemed better than BitRock for our needs (many of these are subjective, of course, so YMMV):
install4j definitely has better support for running custom Java code - it can be done at any point during the installation, and regardless of whether there's any preinstalled JRE on the system.
BitRock uses a more hard-coded sequence of installation steps while install4j is more flexible. In install4j, adding custom screens and forms (with or without custom Java code), asking user for input, etc., can be done at any point, before or after installing any files.
Also some basic things like defining the filesets that are to be copied to the target system, and adding an installation step to replace certain strings in configuration files seemed somewhat easier in install4j.
install4j has better support for JRE bundling
When creating installers on Linux, the look & feel of install4j IDE was nicer (more "native") than that of BitRock
(install4j's licensing options were better for us - we strongly preferred a couple of floating licenses to named licenses for all developers or an expensive "site license")
So ultimately we went with install4j. Here are some more details on why it was impressive:
Its IDE, where you put the installer together, is very simple and easy to use - I could figure out how to do most things I wanted quickly, even without looking at documentation. And when I did have to check something in the documentation (e.g. how to refer to installer variables; how to get started writing custom Java code against the install4j API), it didn't take long to find what I needed.
You can completely customise the screens and actions during the installation procedure, and also add custom screens and actions (coded against their Java API) at any point. This was important to us because we need to reuse existing custom Java code from the old InstallAnywhere installer.
In some small details, install4j seems ideal for Java developers. For example, if you want to add a validation script to check some user input, you can code that very quickly in the install4j IDE itself, using plain old Java, with coding assistance resembling that of IntelliJ IDEA.
We deemed the cost of install4j floating licenses reasonable, considering how good the tool is (and downright bargain compared to the inflated pricing of InstallAnywhere...)
In short, it seemed like the best installer tool available for deploying Java applications.
We created BitRock InstallBuilder, a crossplatform installation tool after some frustrating experiences with InstallAnywhere and specially its cousin (now defunct) InstallShield MP. More than half of our clients use our tool to package Java-based software but the tool is native, not Java-based. That means we have a number of advantages such as native look and feel (incl. Vista, GTK, Qt, etc.) and no need to do self-extraction previous to installation (faster startup, less space requirements) to mention a couple. To answer your specific questions:
Supports calling Java code as part of the installation at multiple points in time (such as when a certain page is displayed, files being copied, at uninstall time, etc.). The code is not compiled in the installer, but it can be called externally and the result used in the installer. If you are more specific about which kind of code that you need I can provide specific sample code. We have a lot of built-in actions for functionality that needs to be manually added to other installers, so you may not need to write that code in the first place!
We support all versions of Windows, including 64bit and Windows 2008 (multiple customers have certified on those platforms using our installers)
We support bundled applications servers, including Tomcat, Resin, JBoss and others. Take a look at BitNami for examples of such stacks that we have created.
We support copying and moving files, substituting values in config files, unpacking files and most other common installation functionality. One of our principles is that the installer should provide built-in support for common installation actions and have an easy, clean interface for invoking external code that is specific to a client's product.
We support bundling JREs, as you mention is often enough just to bundle the JRE directory and setting the appropriate value for JAVA_HOME in the launching scripts
You can take a look at some of our customers such as MySQL, Samsung, Motorola, GitHub, etc. InstallBuilder is a commercial product, but we offer free licenses for open source projects and discounts for small business and microISVs.
Just want to add that my company has used InstallAnywhere for about 6 years but we have decided to move on. The reason is two fold.
First of all their pricing is absolute highway robbery and the licensing is severely restrictive compared to direct competitors like INstall4J and BitRock.
My other problem with InstallAnywhere is the product is only minimally maintained. I have been using the product for 6-7 years through many different versions and bugs are rarely fixed and you surely can't expect new features. Essentially all you can expect is that they will add support for the new version of windows/mac as it comes out. Their support charges are quite pricey, but I have never had a support request actually implemented. When I first bought the product I believe it was from a company called ZeroG who were focused solely on this product. They actually maintained and improved the product. Back then it was the only real ticket and they were leaps and bounds above the competition.
Then it was acquired by Macrovision and then Flexera. Ever since ZeroG sold the product it has been an ancillary product for the owning company and the focus on it has been poor. It seems like it was bought more to complete a suite of products rather than because the company actually wanted to maintain the product.
Word of caution, evaluate these products carefully because you can become tied to them. We would have left the product sooner, but we put so much effort into not just the installer, but setting up an automatic update scheme based on the features/limitation of the product that it is expensive to leave the product because of the labor investment to reproduce this in a new product.
Just my take, but I wouldn't recommend InstallAnywhere.
I can vouch for izPack. It's Ant-based so you can package up an Ant install in it, and that Ant install can contain custom tasks, and/or scripts written within your Ant build.xml (e.g. using Groovy, Beanshell or any BSF-enabled scripting language). So it'll cover your customisable requirement.
I've used it in the past for all the above - unzipping/services/custom code. It's multi-platform, although I can't vouch for that specific instance above (64bit Windows). But if it runs Java, you should be fine.
The one headache is the JRE. You'd obviously require some JRE to run this. However I think you should be able to pack up and execute a specific JRE installation within izPack.
Currently we are using GetDown to handle distribution of our swing applications. We use Tomcat to distribute updates and GetDown to download those updates. It's really flexible and powerful, and much better than java WebStart and because it produces check sum for changes it saves bandwith and downloads just changed files.
A good tutorial : http://www.hascode.com/2012/05/creating-updatable-java-applications-using-getdown-and-the-getdown-maven-plugin/
Project website : https://github.com/threerings/getdown
Deployment in an multi-platform environment is always a big source of troubles. It think that the optimum solution would target the creation of native packages for all platforms, like RPM, DEB or MSI ... the ones that could be installed unattended also.
Developers should work on making the application self-healing and run without installation.
Doing so will payoff in minimize the deployment efforts.
I know this is not quite a solution as you where asking but sometimes you may get better results this way.
Remember that you'll get free updating service on Linux if you follow these.
I still hope Microsoft will add something similar to MSI (and that would not require you to register at them). Meanwhile for Windows you can take a look at Google Updater just released as open source - http://code.google.com/p/omaha/
They released a similar product for Mac OS http://code.google.com/p/update-engine/ but sad that they didn't think about creating one product from these two.
You can try the SetupBuilder Gradle Plugin to create a native *.msi installer with a simple Gradle build script.
It is free.
Supports 32 bit and 64 bit Windows. Also Linux and OSX.
Bundle the Java VM under Windows and OSX, does not required a preinstalled Java VM.
Can run Java Code before or after the installation.
Can create a windows service/daemon.
Has not a GUI but use Gradle. If you already use Gradle as build script language then it is very easy.
you may be interested in launch4j
Jonik, thanks for posting such detailed feedback of your experience. I wanted to write a follow up answer, since you raise some good points.
After certain base requirements are met (which unfortunately InstallAnywhere does not any more) there are not really 'bad' or 'good' tools, but rather tools that are better suited for some projects. It seems you studied carefully all options and install4j will work better for your project. This is probably a good choice, since you have an existing Java codebase from your previous installer that you want to reuse (though I would like to think some of that code would not be necessary with InstallBuilder :)
Regarding InstallBuilder, we support customizing the screen sequence using the <insertBefore> tag (we probably should better document this). It is also straightforward to bundle a JRE (just including the java/ folder in most cases) but I think your criticism is valid: since this is a common task we should do a better job at documenting / making it accessible though the GUI, including drag-and-drop in all supported platforms. We already have in our roadmap improving the GUI in the areas you mention. The funny thing is that a lot of our customers find the XML format so easy to use that they prefer editing it using their programming editors (as if they were editing HTML)
Finally, regarding licensing, our current model does not require purchasing additional licenses if those extra programmers will just be building the installers (not designing them) or purchasing extra licenses for build or continuous integration machines. In any case, a couple of floating licenses for install4j are more expensive than a full Enterprise Site license for BitRock:)
Thanks again for the feedback
I recommend having a look at cmInstall, which can be found at
http://sourceforge.net/projects/cminstall/
It meets almost all your requirements and it's open source. Plus I'm one its developers :).
[yes] Must support running custom Java code as part of installation procedure
[yes] Must support Windows, including latest 64-bit versions like Windows Server 2008; support for other target operating systems is a plus
[can be easily done by using 3rd party libs- e.g.:Tanuki Software] Must be able to install a bundled application server (such as Resin or Tomcat) as a service on Windows
[yes]Must support basic stuff like copying and moving files around, editing configuration files, extracting ZIPs, etc.
[yes - or you can programatically download & unzip it ]Must support bundling a specific version of JRE; at the very least by including a ZIP to be extracted
6.[no - it needs jdk 1.6 installed, support for .exe or .msi is planned for future]Preferably does not depend on a preinstalled JRE (or any other 3rd party runtime environment or library) on target machine; in other words, can produce an independent Windows .exe (or .msi)
[yes] The tool should preferably be cross-platform so that installer development can be done on Linux, Windows, or Mac.
7.[no - the cminstall framework is "developer based" - but easy to use.Just read the tutorials from http://sourceforge.net/project/showfiles.php?group_id=250019&package_id=305489 and see how easy it is to build an installer!] Should preferably have a decent GUI for putting the installer together. Once that is done, however, it must be possible to skip the GUI and make installer building part of automated build process.
I have also reveiwed few of the open source multi platform installers. Here is my comment:
BitRock InstallBuilder: Only Great for free and open source developers as it gives free license for use in open source projects.
InstallJammer: Good free and open source multi platform installer. Only one concern that as soon as one downloads the executable build from InstallJammer, the anti-virus program will immediately delete it. Somehow files built from InstallJammer are being caught as False Positives. You will have to work a bit more security certificate before publishing.
Izpack: Good free and open source multi platform installer. It may be a bit cumbersome for people not used to with ant. May be great when used with GUI front-ends like PackJacket.
I've seen several people recommend IzPack, but I honestly don't know if it meets your requirements. It's at least free :)
Sun offers an open source installer:
OpenInstaller
I'm sure that all your requested features are supported.
But it seems for me a little too hard to configure.
But guess what: It has not only a GUI but also a (pseudo-graphic) CLI.
Nice screenshots and info here.