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.
Related
Java 8 and prior versions have Java Web Start, which auto-updates the application when we change it. Oracle has recommended that users migrate to jlink, as that is the new Oracle technology. So far, this sounds good. This comes with a host of benefits:
Native code on Windows, Mac and Linux
Modularization of the code (although Proguard does this as well)
The use of new, supported technology.
The problem: I can't find the canonical Java solution to auto-update with jlink.
One would think that Java Web Start could continue to be used, especially if one casually reads this document. Notice the fact that Java Web Start continues to be prominently listed. But there's a fly in the ointment: Oracle is deprecating Java Web Start. It's slated for removal in JDK 11. So, what's the official path forward. Failing that, is there a standard way that people proceed?
For the purposes of this question the following are out of scope:
Paying huge amounts of money yearly to someone with an feature-packed enterprise solution. The application to be distributed is already packaged into a single jar that is smaller than 50MB.
Forcing users to run an InstallShield style app to reinstall the new version, and then manually uninstall the old version every time an update is pushed. That's sooo 1990's.
Porting the entire app to be a webapp, rewriting the UI and client side logic to fit in a browser and dealing with all the incompatibilities that entails. The authors of the application worked on GWT and know exactly what web browsers are capable of. Unfortunately, they also know the level of effort required.
Allowing users to continue to run old versions of the application. That, too, is sooo 1980's. Modern apps update quickly, and supporting every version of the application ever released is not tenable. That's what my father's COBOL application had to deal with, and he didn't enjoy it. I'm hoping technology has progressed.
Continuing to use Java Web Start. Until/unless Oracle changes its mind, Java Web Start is a doomed technology.
In May 2019 commented to watch the OpenWebStart project.
Now (October 2019) it is time to give OpenWebStart serious consideration. While not yet feature complete, a alpha beta release of OpenWebStart is now available for download under a "GPL with Classpath exception" license.
The OpenWebStart Technical Details page states:
OpenWebStart is based on Iced-Tea-Web and the JNLP-specification defined in JSR-56. It will implement the most commonly used features of Java Web Start and it will be able to handle any typical JWS-based application. We plan to support all future versions of Java, starting with Java 11. In addition to Java 11, the first release of OpenWebStart will also support Java 8.
The page goes on to state that OpenWebStart will support interactive installers with auto-update, and non-interactive installers. Some JNLP features will be supported, and it will include a replacement for the Java Control Panel. A more comprehensive list of planned features1 and their implementation status is provided in the feature table.
1 - If you have a requirement that is not on their feature list (e.g. jlink support), you could contact the OpenWebStart team, and offer a suitable incentive (e.g. money to pay developers) to implement the feature for you. They also offer commercial versions of the software for paying customers.
Disclaimer: I have no connection with the OpenWebStart project, the company (Karakun) or the project sponsors. This is not a recommendation.
I had a similar problem in a past project. We needed to migrate from Webstart to another technology.
The first approach was to install IcedTea. It is directly bundled with the AdoptOpenJDK Project.
But as far as I understood the problem, Java wasn't meant to be installed on the Client side like this anymore and we didn't want problems with all of our customers.
Our solution was then building an own specific Executable, which connects to the server, ask for enviroment settings from the server side, and then download and extracts the JLink Java. So we could use the old technologies and just wrapped it in an Executable.
Last thing done then was redirecting to the download location of the Executable when calling the jnlp-URL.
Do you use maven?
I've resolved my similar problem with maven (I need to update an EAR).
My main app (the ear package) has a pom.xml with listed the dependencies and repositories.
The dependencies have the <version> tag with a range (documentation) as in this example
<version>[1.0.0,)</version>
That means : get version 1.0.0 or newer of the dependency. (You can put also an upper bound to the version, [1.0.0, 2.0.0) so if you develope a new version, it is not used in old app)
In the repository section I added my personal repository.
Now, in the remote machine I need only to rebuild my ear package with maven : the compiler download the newer version of my jar and put it together.
You need a system to check if there are newer dependencies version and warn the user to update the app and also lock its work (you can't work if you don't update). Maybe you need a little app to make users do the rebuild process easily. It's 1990's but a lot of desktop-app works in this way
PRO
This schema can be used in a lot of different projects.
CONTRO
You need to build the app in the remote machine, so the client must have a JDK and access to your repository (like artifactory);
You must write code in different jars and add them like dependencies in the main archive.
You must change JAR version each time and publish on the repository (this could be a good practice)
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.
DISCLAIMER: I'm relatively new to Linux. I debated putting this on SuperUser or ServerFault because the answer does require an explanation of Linux as a system (and not a specific programming problem), however I'm interested in this from a Java developer's perspective, and I argue that this is a specific problem because where I install GlassFish greatly impacts my Java configuration, and ultimately, app configuration. Not to mention posting this question on those other sites probably won't garnish any attention from a Java developer, more over system admins, who may not know enough about Java to weigh-in fully on this decision.
I'm trying to decide where to install GlassFish and it seems to me I have (realistically) 4 viable options:
/opt/glassfish/
/usr/local/glassfish/
/home/myUsers/glassfish/ (which is what all the OGS docs show in their examples)
/home/ogs/glassfish (as its own user, similar to how Apache web server is sometimes setup)
I'm wondering what the pros (taking into consideration the nature of how Linux treats these directories differently, the FHS, etc.) and cons of each approach are.
I've read that there are mounting/paritioning benefits to installing it under opt/. However, I normally install 3rd party software to usr/local/, so I'm a little unsure about that as a strategy.
The Oracle GlassFish Server (OGS) docs all demonstrate (but never outright recommend) GlassFish being installed under your home directory (home/myUser/).
Then again, I've read that it is fairly common to install daemon-type services (which is what I would imagine I would be using GlassFish as - where I start it once and it only comes down for routine maintenance or crashes) as their own user (home/ogs/glassfish/).
I'm sure this decision is also impacted by how I'm going to use GlassFish, so let me qualify this question with a few constraints:
I intend to deploy 4 OGS instances across 4 VMs on the same physical machine and cluster them into the same domain (1 of the 4 server instances will be the admin server for the domain)
Several applications will be deployed to this cluster (all 3 non-admin nodes) at the same time, and should be running 24/7/365 except for when they crash (hopefully not often!) or when I need to maintenance or tune them
Each application will be farily large and I would like to configure them with real admin, not "bare bones" de minimis, default settings
If these don't provide specific-enough information to help make this choice, please ask and I can be more specific.
I guess, when the dust settles at the end of the day, I'm looking (more or less) for a matrix with each of the four directory options (plus any other obvious ones I've omitted) compared against their respective pros & cons.
There's also the option of using your Linux distro's package management system to install Glassfish. On Ubuntu for example, you could install it using
sudo apt-get install glassfish-appserv
and let it get installed to wherever the package owner thought it should be installed.
I myself tend to steer away from the above option, as I like to exert my own control over which exact version of Glassfish (or any other Java server/software) is installed and where, but I just wanted to throw that out there, as it's one of the things you could do.
Now for the individual options you've provided:
/opt/glassfish/
This is the preferred option as far as I'm concerned. It keeps the software on a separate directory outside of the regular Linux installation, and allows the mounting and partitioning benefits you mention.
/usr/local/glassfish/
I don't like this much, because /usr/local is generally used by third-party software that is installed using the distro's package management software (apt/yum/etc), and on most distros has directories like bin, etc and lib under it. Putting a directory for glassfish under it, would make it out of place.
Also I prefer to keep system directories separate from custom software that doesn't use the distro's package management tools.
/home/myUsers/glassfish/ , /home/ogs/glassfish
These 2, I would not recommend.
They are only described in most places, because the author doesn't want to assume that the user has root access on those boxes, in which case the home directory would be the only one you'd be guaranteed to own. If you own the system and are managing it, those restrictions don't apply.
Remember, home directories are for specific users. I always recommend server software being managed with individual users' accounts that have the required privileges. Putting software in someone's home directory would mean that you either
Give everyone who needs to manage Glassfish, the password to that user account
Give multiple users read/write access to the home directory of a specific user.
Either way, that's not good system administration policy.
There's not much of a Java perspective here, but if you ask me, there doesn't need to be.
Regarding the prior recommendation, some tradeoffs remain:
If placed in /opt or /usr/local, you will have to have read/write access to those directories, meaning that you will have to have root access to the box. In some environments (where IT controls the platform), IT will not let you have root access. You would have to delegate to IT the responsibility of installing, patching, and upgrading the GlassFish binaries.
If placed in /opt or /usr/local, then you will also have to place the domain directories (--domaindir) in a separate location unless you want them owned by root (unlikely). This was the default in GlassFish 2.x RPM installs on Linux. GlassFish 3.x does not have RPM installs (from Oracle, anyway), but you can still split the two. This isn't a bad tradeoff, but something you should understand.
If placed in a "home directory", then you have rights to upgrade the core binaries, install patches, etc, separate from IT. There is good/bad/ugly in this approach depending on organizational responsibilities.
Hope this helps.
What I'd like to ask is if anybody knows about an hardware USB-dongle for software protection which offers a very complete out-of-the-box API support for cross-platform Java deployments.
Its SDK should provide a jar (only one, not one different library per OS & bitness) ready to be added to one's project as a library.
The jar should contain all the native stuff for the various OSes and bitnesses
From the application's point of view, one should continue to write (api calls) once and run everywhere, without having to care where the end-user will run the software
The provided jar should itself deal with loading the appropriate native library
Does such a thing exist?
With what I've tried so far, you have different APIs and compiled libraries for win32, linux32, win64, linux64, etc (or you even have to compile stuff yourself on the target machine), but hey, we're doing Java here, we don't know (and don't care) where the program will run!
And we can't expect the end-user to be a software engineer, tweak (and break!) its linux server, link libraries, mess with gcc, litter the filesystem, etc...
In general, Java support (in a transparent cross-platform fashion) is quite bad with the dongle SDKs I've evaluated so far (e.g. KeyLok and SecuTech's UniKey).
I even purchased (no free evaluation kit available) SecureMetric SDKs&dongles (they should've been "soooo" straighforward to integrate -- according to marketing material :\ ) and they were the worst ever: SecureDongle X has no 64bit support and SecureDongle SD is not cross-platform at all.
So, has anyone out there been through this and found the ultimate Java security usb dongle for cross-platform deployments?
Note: software is low-volume, high-value; application is off-line (intranet with no internet access), so no online-activation alternatives and the like.
-- EDIT
Tried out HASP dongles (used to be called "Aladdin"), and added them to the no-no list: here, too, there is no out-of-the-box (out-of-the-jar) support: e.g. end-linux-user has to manually put the .so library (the specific file for the appropriate bitness) in the right place on his filesystem, and export an env. variable accordingly.
Full disclaimer: I work for a company that makes software-protection dongles (CodeMeter). But I believe we might have a solution that meets your requirement: we have a single API for all platforms (Win, Mac, Linux, etc both 32- and 64-bits). Each end-user machine merely requires a runtime (service on Windows; daemon on Linux). We use a native Java API which uses TCP/IP to call our runtime, so no special device drivers are required. You can do activations either before you ship the dongle (pre-programming), or via file exchange (NikeNet) on deployments with no Internet access, or you can remove the dongle, take it to a machine that DOES have Internet connectivity and update the license there.
At a higher level than the API we have AxProtector, which is an automated protection/encryption tool that you can use to test our protection system with no source code changes. This would let you test the implementation on all platforms you are interested in--you don't need to create multiple versions for different platforms.
We had a Fortune 100 company use this to protect a Java app that ran on non-Intel Solaris, so we know it's been stress-tested as a cross-platform solution.
We have a free fully-functional eval system which we can get you asap. If you email me at the email address in my profile we can ship you out an SDK and help you quickly determine if this will solve your problem.
You can use Dinkey Pro dongles to achieve exactly this. While they do use separate native libraries for each operating system and architecture you just need to call their Java API and it takes care of any platform specific bits. Wrap the libraries up in a JAR file with the .class (the API) and you've got a neat solution. The dongles themselves are driverless.
I can only recommend to avoid the SecuTech UniKey system. During evaluation the product met all requirements we needed. We started integrating this solution and discovered one issue after another.
Here is a short list of the major issues that are part of the SDK 6.2.7:
Enveloper settings change randomly when saving and loading the same solution (Video).
DLL files that are wrapped with the enveloper do not load.
The console version of the enveloper for script based builds does not work. It is unable to wrap exe/dll's that can be wrapped with the GUI based version of the enveloper.
Support is reactive but does not really tackle the problems.
After all we wasted almost a month of work integrating this protection system, but now have to switch due to the massive quality issues.
I am working on a java based application and we are looking to ease our deployment of updates. Up until now, we've always simply sent out new install packs & had the sysadmin's on our customer sites roll out the upgrades - painful for a large number of users.
what I'd like to do is something similar to java webstart (or eclipse p2) - when the application starts, it checks for updates in a specified location and then downloads the updates prior to starting.
But here's my problem - I want more control over what's done outside of the scope of plugins & jar files. For example:
I'd like to be able to upate my JVM (we ship a modified version with additional security features).
I need to install DLL's - possibly local to the jar files, sometimes to windows
Occasiontally run MSI's to install windows components (e.g. printer drivers).
I need to modify config files & the registry.
I have found a few applications that support this (such as AppLifeUpdate at http://www.kineticjump.com/) but they tend to be .NET focused and it seems a bit perverse to introduce a .NET dependancy on a java application ;)
I know I could write my own here, but if there is already a 3rd party library out there that supports this kind of facility, then it would make my life a lot easier.
So, has anyone else had a similar problem & knows of some products I could look at?
Thanks, Brian.
I have done similar things but on Linux/Unix, so can't suggest any specific products for Windows. But I always found helpful to either package everything in OS format and distribute everything that way (rpms, debian pkg, Solaris pkg, ...) or have the platform deployed through OS mechanisms and have the application deployed through Java mechanism (Web start).
The reason is that sysadmins typically don't like things that magically update themselves without them knowing or in a way that does not follow standard practices. That is: you can't expect to make your life easier if you are not sure that you are not making their life more difficult...
Also: whatever work I do at the OS level, I do it with OS tools. If on Windows it means using .NET, I would very much consider using that...
Hope this helps!