Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Java is one of my programming languages of choice. I always run into the problem though of distributing my application to end-users.
Giving a user a JAR is not always as user friendly as I would like and using Java WebStart requires that I maintain a web server.
What's the best way to distribute a Java application? What if the Java application needs to install artifacts to the user's computer? Are there any good Java installation/packaging systems out there?
There are a variety of solutions, depending on your distribution requirements.
Just use a jar. This assumes that the user has the the correct java version installed, otherwise the user will get "class-file format version" exceptions. This is fine for internal distribution inside a company.
Use launch4j and an installer like NSIS. This gives you a lot more control, although the user can still do stupid stuff like un-installing the java runtime. This is probably the most popular approach, and what I currently use.
Use Webstart. This also assumes that the user has the correct java version installed, but it's a lot easier to get going. My experience is that this is fine for tightly controlled intranet environments, but becomes a pain with larger deployments because it has some many weird failures. It may get better with the new plug-in technology in Java 1.7.
Use a native-code compiler like Excelsior JET and distribute as a executable, or wrap it up in an installer. Expensive, and it generally ties you to a slightly older version of java, and there is some pain with dynamic class-loading, but its very effective for large-scale deployment where you need to minimise your support hassles.
advanced installer makes it easy to package java apps as windows executables, and it's quite flexible in the way you can set it up. I've found that for distributing java applications to windows clients, this is the easiest way to go.
JSmooth is a simple program that takes your jar and wraps it up in a standard windows executable file. It comes with a simple GUI that allows you to configure the required JVM, bundle it with the application or provide an option to download it if it's not already installed. You can send the exe file as is or zip it with possible dependencies (or let the program download the extra dependencies from the net on startup). It's also free, as in beer and speech, which may (or may not) be a good thing.
If it's a real GUI-having end user application you should ignore the lanaguage in which you wrote the program (Java) and use a native installer for each of your chosen platforms. Mac folks want a .dmg and on windows a .msi or a .exe installer is the way to go. On Windows I prefer NSIS from NullSoft only because it's less objectionable than InstallShield or InstallAnywhere. On OSX you can count on the JVM already being there. On Windows you'll need to check and install it for them if necessary. Linux people won't run Java GUI applications, and the few that will, know what to do with an executable .jar.
It depends on how sophisticated your target users are. In most cases you want to isolate them from the fact that you are running a Java-based app. Give them with a native installer that does the right thing (create start menu entries, launchers, register with add/remove programs, etc.) and already bundles a Java runtime (so the user does not need to know or care about it). I would like to suggest our cross platform installation tool, BitRock InstallBuilder. Although it is not Java-based, it is commonly used to package Java applications. It can be easily integrated with Ant and you can build Windows installers from Unix/Linux/Mac and the other way around. Because the generated installers are native, they do not require a self-extraction step or a JRE to be already present in the target system, which means smaller installers and saves you some headaches. I also would like to mention we have free licenses for open source projects
Although I haven't used NSIS (Nullsoft Scriptable Installer System) myself, there are install scripts that will check whether or not the required JRE is installed on the target system.
Many sample scripts are available from the Code Examples and Real World Installers pages, such as:
Java Launcher with automatic JRE installation
Simple Java Runtime Download Script
(Please note that I haven't actually used any of the scripts, so please don't take it as an endorsement.)
executable files are best but they are platform limited i.e. use gcj : http://gcc.gnu.org/java/ for linux to produce executables and use launch4j : http://launch4j.sourceforge.net/ to produce windows executables.
To package on linux you can use any rpm or deb packager. For win32 try http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System
I needed a way to package my project and its dependencies into a single jar file.
I found what I needed using the Maven2 Assembly plugin: Maven2 Assembly plugin
This appears to duplicate the functionality of one-jar, but requires no additional configuration to get it going.
For simple Java apps I like to use Jar's. It is very simple to distribute one file that a user can just click on (Windows), or
java -jar jarname.jar
IMHO, jar is the way to go when simplicity is a main requirement.
I develop eclipse RCP applications. Normally to start an eclipse application an executable launcher is included. I include the java virtual machine inside the application folder in a /jre sub directory to ensure that the right java version will be used.
Then we package with Inno Setup for installation on the user's machine.
What's the best way to distribute a
Java application? What if the Java
application needs to install artifacts
to the user's computer? Are there any
good Java installation/packaging
systems out there?
In my experience (from evaluating a number of options), install4j is a good solution. It creates native installers for any platform, and is specifically geared towards installing Java apps. For details, see "Features" on its website.
install4j is a commercial tool, though. Especially if your needs are relatively simple (just distribute an application and install some artifacts), many other good options exist, including free ones (like izPack or the already mentioned Lauch4j). But you asked for the best way, and to my current knowledge install4j is the one, especially for distributing larger or more complicated Java (EE) apps.
The best answer depends on the platform. For deployment on Windows, I have had good results using a combination of one-jar and launch4j. It did take a little while to set up my build environment properly (ant scripts, mostly) but now it's fairly painless.
Well from my point of view the superior distribution mechanism is to use something like ClickOnce, or WebStart technology. You just deploy the version to the server and it gets automatically to the clients when the version is released.
Also the Eclipse RCP platform contains UpdateManager that does what WebStart do, but also much more.
Since I am using Maven2 for building, the deployment is just a piece of cake: copy the built jar to the location on the server, update the jnlp file if needed and you are done.
installanywhere is good but expensive one - i have not found (as) good free one
I would zip the jar file along with other dependent jars, configuration files and documentation along with a run.bat/run.sh. End user should be able unzip it to any location and edit the run.bat if required (It should run without editing in most of the cases).
An installer may be useful if you want to create entries in start menu, desktop, system tray etc.
As a user I prefer unzip and run kind of installation (no start menu entries please). However People outside IT industry may have different preferences. So if the application is largely targeted for developers zip-run.bat route and applications for general public may be installed using a installer.
The documentation for ROS is terrible.
One great irony is that the Groovy and ROSJava versions of ROS was created to allow developers on platforms like Windows to utilize the great robotics SDK, while all the installation instructions are still geared toward linux/ubuntu users.
The ROSJava core documentation says:
TODO: write a guide for a strictly java installation.
I've tried to follow the instructions here on the Google Code project, but seeing as all the instructions assume I'm running Ubuntu, it is very difficult as a traditional Windows/Web developer to translate into windows instructions on my own.
The link is also broken to the GIT repo, it is moved to github: https://github.com/rosjava/rosjava_core.git
If you were looking for rosws documentation, its here. Another broken link: http://www.ros.org/doc/independent/api/rosinstall/html/
Now, wanting a versatile IDE for coding, I chose Eclipse because it can handle Python, Java and c++. Now I have no idea how to build this project with Gradle and Maven-- Heck, I'm not even sure I should be building it.
Is there a definitive installation/build tutorial for ROSJava on Windows? If not, I think it would greatly benefit the community if somebody could create a walk-through that can help developers make their first "Hello World" in robotics. I've done some processing and some light Java before, but nothing too serious. The manual should assume you are new to Java, ROS and all the dependencies/build helpers/compilers. I feel like all the instructions from Google Code and ROSWiki assume you're familiar with many tools and dependencies or are aware of the historical context of ROSJava versus Groovy versus Linux implementations. Many of the necessary tools are off the beaten path for a C#.NET, Objective C or Javascript/Web developer.
Also, a big detriment is that the pre-compiled version of the ROS SDK is outright missing from ROSWiki. "Page Does Not Exist" so, us newcomers have to also install 10-16 dependencies for compiling the core (not to mention figuring out how to configure and use them).
Additionally, build scripts named in the Wiki don't even exist yet.
Currently, I've not even gotten far enough to start encountering problems like this: Gradle Eclipse Plugin
While the ROS documentation has improved in general during the past years, the ROS Java documentation is even currently not as detailed.
Using ROS_JAVA is in fact as easy as using any other dependency if you do not use custom messages.
ROS_JAVA can be practically divided in two parts.
An API to create your own servers/clients and publishers/subscribers
A pure Java roscore
The API is perfect for accessing and consuming ROS based services/topics/actions written in any language.
The pure Java roscore can be used for testing, or installation in any system that runs Java, in cases where the C++ ROS is not supported. However it is not as complete as ROS C++.
If you do not use custom messages you can easily add the required dependencies.
The following configuration should work in gradle.
repositories {
repositories {
mavenCentral()
maven {
url "https://github.com/rosjava/rosjava_mvn_repo/raw/master"
}
}
}
dependencies {
implementation 'org.ros.rosjava_core:rosjava:[0.3,0.4)'
implementation 'org.ros.rosjava_bootstrap:message_generation:0.3.3'
implementation 'org.ros.rosjava_messages:std_msgs:0.5.11'
}
This is part of a simple "Hello World" pure Java project that I have published here.
For programming only in Java /ROS Java you do not need to install ROSjava in windows. (This is also an article I had written trying to provide some quick instructions on the issue.)
If you also need to compile messages without a ROS installation then you can also do this manually through java.
Finally it is worth noting that ROS Noetic can be installed in windows. While this is not a requirement for development using ROS java.
I've been assigned to develop a software on Linux, opensuse 11.4. Now the issue is that I'm a Java developer and I want to make that software on Java. Can I use Eclipse IDE for this software? It will be a desktop application on Linux. If Eclipse supports this type of development, what plug-ins do I need to get it started?
Plus I need to use some library routines as well. Can I do all this using Java and Eclipse IDE and some additional plug-ins?
Any help would be highly appreciated.
You may not realize it, but there are two distinct parts to this question. The response depends somewhat on whether you've already decided what GUI toolkit to use. The two obvious choices for a Java app are AWT/Swing (Java's "standard" GUI frameworks) or Eclipse's SWT/RCP. You see, Eclipse is more than just an IDE, it's a platform on which you can build applications. Here is the official description, and here is a very good intro and tutorial. Of course has plenty of tooling built-in to help you develop an RCP app.
If you're looking to stick with AWT/Swing, then Eclipse also has tooling to help with that. Specifically, WindowBuilder (WB) is included in the Eclipse IDE for Java Developers package that you can download. WB helps a lot in designing and implementing your GUI.
Java is (almost) write once, run anywhere (WORA). Thus any Java program you write should be able to run on any architecture and operating system that supports Java. In other words, you don't need to do anything extra to make your program run properly on Linux.
Eclipse can package your application in nice JAR files and the like which can be distributed to any OS.
Just download Eclipse IDE for Java Developers. You won't need any plug-ins.
Now, don't get me wrong, I am a very competent programmer, but when I program, I typically develop things for the web using scripting languages like JavaScript, PHP, Python, SQL, etc. If I want to develop Java software (I am relatively experienced in Java), how do I distribute it?
Is there any good way to package up Java software in a nice little executable, send it out, and have it run? Alternatively, is there any good way to package up Java in some sort of installer, and send it out to be installed and run?
I'm using Launch4J http://launch4j.sourceforge.net/ it will generate an .exe executable for Windows, if the targeted system don't have JVM, it will tell user to download and get JVM.
You can package Java applications in so called jar-files using the jar tool or any competent Java IDE. These jar-files are self-contained and seldom need any installer.
These .jar files can easily be distributed and executed.
If you're used to web-development, you may also be interested in the Java Webstart technology.
Some links to get you started.
Export to a .jar-file in Eclipse
Lesson: Java Webstart
I have found two approaches to work well, depending on the needs of the end user.
1) Java WebStart - allows for central distribution and easy maintenance, but works best for online users. Require you to have a web site to locate the files - these days this is easy to do on the Google Application Engine.
2) Wrapping up the Java program in a single jar using one-jar, and then using jsmooth to generate an .EXE file which ensures Java is available, extracts the jar-file and invokes Java on it. This works well for users not always on the net, where you want the launch process to be transparent, but is less easy to upgrade than the webstart approach.
I use Maven to handle all the dependencies of my projects and that way when you utilise Maven to build your projects they will compile into one nice executable jar that contains everything so you dont need to worry about getting all your third-party jars in the right place etc.
There are a couple of ways: one is to create an installer that allows your user to install and run it. For this you can take a look at NSIS.... or you can just use Java Web Start where your user can just click the link and launch your application.
Here you will find a large set of options: Open Source Installers Generators in JavaIt is very useful for the "naive" customer or user of your application, to make the installation process as painless as possible. Let them install whatever is needed, DBMS, JVM, JMF and additional options via one installer.
You can also consider use one of the rich client platforms available for Java. The learning curve is probably a lot higher than just creating a jar file and ship it, but you will get a lot for free when it comes to distribution. (Think Eclipse with auto update through an update site).
Do a search for "Eclipse RCP" and "Netbeans RCP" and you'll find the two biggest contenders here. I also performed a serach for "eclipse RCP installer" and one of the hits seems interesting:
http://download.instantiations.com/RCPPackagerDoc/integration/latest/docs/html/gettingstarted/GenInstaller.html
I personally like izpack. It generates a jar file installer that you could wrap up in launch4j, supports things like windows specific shortcuts, is highly customisable through XML and hooks directly into ant.
OneJar is great for smaller stuff, but for larger programs or applications it's nowhere near as flexible and in my experience is rather slow.
Hello you can make an installer for your application.
In the link below you will find a nice help about izpack installer.
http://www.imrantariq.com/blog/?p=89
Link below contains a detailed pdf to make installer with izpack.
http://www.imrantariq.com/blog/?attachment_id=112
cheers
I authored a Java freeware (closed source) product that I deploy on a web host and distribute via JNLP, inclusive Linux clients.
I plan to suggest this product for inclusion into several Linux distro, if possible "as is" (JNLP-based).
Can I already contact distros, or I need to reconfigure something (deploy on another host, convert JNLP to something, etc.)? What is your experience?
I would say that a freeware JNLP application is pretty much the opposite of what Linux distributions would tend to include.
Firstly, JNLP will not work with the native package management solution. If you wanted to get an application included in a distribution it would need to be package in the native format and updated in the standard way.
Secondly, most distributions will favour open source packages and many will not include non open source packages in their default repositories. Some distributions may have specical non-free repositories. Up until OpenJDK you may not even Java itself would be in these repositories.
In my opinion you would be better trying to build a user base on your own as you then have complete control over releases etc.
Generally Linux distros aren't very interested in things they can't integrate into their release schedules. Since JNLP allows you to deploy a new version at any time, they can't do a version freeze before release. This will exclude you from most distros - Debian even removed Adobe's flash plugin for this very reason, and if they'll remove Flash, don't expect them to make exceptions for a less well known application.
If you're willing to distribute it as just a plain .jar, you might be able to get it in - for debian, you'll want to read the Debian New Maintainer's Guide and Debian Policy on how to package things, submit an ITP (intent to package), upload a package, then seek sponsorship on the debian-mentors mailing list. More info can be found at the Debian mentors FAQ. Packages submitted to Debian will also make their way into Ubuntu in due course.
Other distributions will have different policies, of course; if in doubt, check their faqs, or ask on an appropriate mailing list for the distro in question.
Figure out a way to package it properly on each of the platforms you want to include your software on, and prepare for rigid software management (freezing, multiple versions etc if you want the code included in the standard installation.
Otherwise you may be able to create a simple package just containing the link to the JNLP page which may be included in the non-core parts. It is worth a try.
What applcation are we talking about?
Java programs tend to be very difficult to package and maintain. Therefore guidelines vary from distro to distro. So you should have a look at the specific guidelines for some popular distros first.
In addition to that: Everything that updates itself independently from the package manager can be real pain for the user and maintainer of the package so you should consider a different distribution model for inclusion in linux distros.