Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
We're having huge issues with Java Web Start in production. We're afraid to release because every time we do, help desk gets calls from 1/3 users getting an "unable to launch" error. It's hard to tell whether it's because of user error, cancellation in the middle of download, poor network connection or anything. But the bottom line is:
We find it terribly unreliable.
What are the alternatives for deploying and updating a rich Swing application? Either free or commercial, I'm more interested in features and robustness.
Reliability is key, but I would also like to have the following:
Install once, update automatically from a simple HTTP hosting like JWS
Differential updates
Support for multiple configurations (think of 30 instances which may have different versions of the application or different launch parameters - would be nice not to build 30 artifacts each time)
Win / Mac / Linux support. Hopefully one that does not mean I have to maintain 3 builds for each instance.
I feel your pain, the biggest issue I've had with JWS is visibility, that is, what is it doing and why is it doing it. Most of our issues were related to internal proxies (Java seems to really not like authenticating proxies) and the wrinkles seem to be ironed out for the moment. Nevertheless, I did consider simply writing a replacement. This is not as crazy as it sounds, JWS does an awful lot of stuff that I don't really care about, namely, integrating with the web browser and checking JVM versions. Consider the following scenario:
You launch a Java application (the launch app). This application takes a single parameter which is a URL of a JNLP file.
The launch app hashes the URL and uses this as the basis for a local folder (repository) in which to store any downloaded jars for the app. If the repository doesn't exist, it will create it.
The launch app attempts to download the JNLP pointed to by the URL. If it can't download it, it will just launch whatever is in the repository (maybe warning the user)
If it can download the JNLP, parse it and list any jars that need downloading. If you already have the jars, use something like Apache HttpClient in order to determine whether the server has a newer version and download if required. The important point is that any downloads should be stored in a temporary folder. Once ALL of the downloads have succeeded, you can apply these to the local repository. Ideally, you will back up what is already there in order to allow some sort of rollback procedure.
This should provide some very significant advantages over regular JNLP:
Visibility, you can log exactly what is happening
Much better failure modes: if the download gets interrupted just launch the version that's already there (obviously, this won't work if the interrption occurs on the first download), if you feel like telling the user about it then do so.
By running as a local app you should avoid running into issues with signing of jars, I honestly don't understand the Java Web Start security model with respect to signed jars but it seems that if different classloaders are involved, JWS will complain about it (I think)
Sadly, I'm not in a position to fire you over a working version of the above, I did start a prototype but suspended it. I may have to return to it in future in which case, I'll be happy to share the finished version.
Cheers,
Phil
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/
You could use an installer: for example Install4j.
You can find a list of installers here: What are good InstallAnywhere replacements for installing a Java EE application?
With Java Web Start being deprecated by Oracle, we are considering using Microsoft's .NET Click Once to download and launch our Java application.
We will have a Click Once .application file run a little MS program that detects Java, downloads our latest jar files and then launches our Java program using the detected version of Java and the Jar files.
Of course, this is only a solution for Windows machines, but we are customers are exclusively on Windows, so this works in that environment.
MS's Click Once: https://learn.microsoft.com/en-us/visualstudio/deployment/clickonce-security-and-deployment
You could also give Zero Install a try. It's cross platform (Linux, Win, Mac), offers jrd download and auto update and has a nice system integration.
Drawback in my eyes that its not easy to handle..
http://0install.net/
Related
I have stumbled across many things, OSGi, Install4j, JWS(Java Web Start deprecated), Jgit, etc. I want to know what the best solution is for a very small java application that will be installed on the companies computers to interface with USB Scales. If our database updates I want to be able to go and update the git repository and have the Jars already on all of the machines update to the new jar when one is available. This small application will be used probably 100 times a day, but is very small. If the jar needs to pause to update that is fine. I don't want to recreate the wheel. Is the best option a two part system where one jar is the Updater and one is the application? Please help I am a bit lost on this as most of the information is at least a few years old. I have also found this Tutorial on OSGi but not sure it is what I need.
I have a question about how to manipulate files from the browser, currently we are using a java applet. To create some folders, replace/delete save some files/folders and execute a shell command with parameters. As we know Chrome no longer supports the npapi and therefor java applets, FireFox will soon follow and my guess is that IE will not stay behind forever.
So the actual question is what's the best way to go?
Should we think about creating plugins (but this then should be done for all major browsers - a lot of work)
Or do you recommend to install an external program, what we can launch on the users system? By for instance associating a specific extension, or by adding a url scheme?
What about this Java Web Start? Does this allow us to communicate with the domino api?
Any other technologies that would be better?
The website we are building is using IBM Domino 9.0.1 XPages (JSF).
Answering to your use case: content management system.
For adding files the HTML5 files API should do all you need. There are plenty of examples including multi file uploads.
It gets trickier when you want to provide a round-trip edit experience. Like you click something and Word, Excel, Impress, Photoshop opens and you edit. When you save it all goes back to Domino.
The solution here is wevDAV. You can even expose Domino views as folders in Explorer / Finder / Nautilus.
For Domino there is a project on OpenNTF that implements WebDAV for documents/attachments on Domino (I wrote it). It might be your best bet.
I think we should be making a distinction here:
things like file access can be done using HTML5 file access, but
things like local administration definitely aren't something that need or should be done from within the browser.
In fact, I always hated that Java suggested that users "need not install any software" to do this and that on their machine, which was a straight lie, considering they downloaded Java Software, had to tell their Java Policy framework to trust that and then that software was able to make local changes. That's just as unsecure as downloading any (signed) executable and making your user execute it.
Java's portability¹ doesn't apply to your use case, as it seems; "executing a shell command" sounds as non-portable as it gets. So, in the end, you either only have one platform you address, or one solution for every platform, in which case you gain no portability by the fact that the same Java executable can run on all JREs (given that's the case, even).
I'd say: It's a good time to let Java for Desktops die, especially since you don't seem to be doing anything that Java is good at² in your application.
As it sounds, the average installer framework can do what you want without you writing any code. There's plenty out there, especially for Windows, which you seem to be addressing; take microsoft's .MSI as an example. You'd end up with a two click, signable, trustable, updateable solution that wouldn't need the user to keep a JRE installed or secure at all.
CLARIFICATION: I really don't hate Java; I don't find it's the greatest language or has the best ecosystem, but whatever makes your application work is fine.
Now, you mention:
To be clear, we are creating a Document Managing System, which used to be on the Lotus Notes client and that we are trying to port to the Web.
That does in fact sound like it might be a good idea to chose any browser and embed that. In fact, Firefox is "merely" an application around a browser core, and you might just modify it (e.g. by writing an extension) to fit your needs. It's not really a "web application", that way, but it would meet your requirements of integration with a web application and local administrative access. I furthermore recommend thinking twice about the shell scripts you need to run locally -- maybe their job can be more easily replaced by another program or even something that is "web compatible" than calling them with local privileges from your web application.
¹ (which was a big thing back in the day, but honestly, Java applications nowadays are about as portable as your average .Net or Qt based application on desktop OSes, but never quite feel completely like home -- it's like portabilities ugly sister if you're portable, but only offer the minimal common subset of functionality and look and feel on each platform)
² ... whatever that might be!
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
I am a Windows developer (with some iOS Objective-C experience) and I am trying very carefully to choose the correct language to make a fairly simple daemon for the MacOS.
The app will download and upload files, communicating with our .NET web services that are already in place.
The installation will be done by non-technical everyday users, so asking them to do a lot of configuration/scripting on their end is not an option. A sleak package is a requirement.
I see my choices as:
Objective-C
Java
Mono
Scripting
Objective-C has the advantage that it is native, but I'm not the strongest with this language yet.
Java is very easy, but do all users have it? Is it going to be a problem asking people to install it?
Mono will let me leverage my .NET skills, but will it install elegantly as a daemon?
Scripting may be an option as it is very simple what the app has to do, but is this the norm, to deliver a product like this?
--
EDIT
There will be no GUI. I'm okay with not hiding the code, although a UID/PWD will be necessary in order to access the webservices (different for each client). It will always be running, for all clients.
Objective-C/Cocoa or C (esp. using Core Foundation) would certainly give you the most native implementation with performance and OS integration benefits.
Java is reasonable and will be built-in. You'll need some basic scripts to bootstrap it, but not much.
Mono is also reasonable and can be relatively easily installed by the user. You'll need to point them at the download page and specify that they only need the runtime, but it's do-able. Depending on licensing, you may be able to include the Mono runtime installer package within your own installer package so it's installed at the same time as your daemon.
Naturally, scripting languages will most likely leave your code exposed and modifiable, so you may want to avoid that route if that's of concern.
Regardless of the language used to develop the daemon, you'll want to consider installation & management.
For installation, Mac users are used to two installation methods: installing via an Installer .pkg file that the user double-clicks and then is brought through the installation process or by dragging an application into their Applications folder and double-clicking to launch. As a developer, the former gives you a lot of control over including README/license text, running pre- & post-flight scripts, building meta packages to install one or more packages (as mentioned above re:possibly including Mono runtimes right in your own installer), and also gives the OS & user the ability to see what files will be installed, where, and when (post-installation) if they so wish. Alternatively, many daemons will be actual Mac OS X applications which will then install themselves as background processes upon the first launch. The former would be independent of your language selection, but the latter would lean towards a Objective-C/Cocoa implementation.
This brings me to management. Most daemons will want to be run through launched as either a LaunchDaemon (for all users, typically launched at boot) or a LaunchAgent (for particular users, typically launched at login). If you integrate well with launched everyone will be happier and should be do-able in any of your language options.
The question then becomes will the user need to manage the daemon at all? If so, this is most frequently implemented as either a MenuExtra or a Preference Pane. In either case, the daemon could be developed in any language and controlled (esp. via launched) by the MenuExtra/Preference Pane, but in some cases the MenuExtra could actually function as the daemon and so you'd want to develop in Objective-C/Cocoa.
See also: Apple's Designing Daemons & Services documentation.
Objective-C is the best bet, native, fastest and suitable for a daemon, otherwise you can develop it in Java 6 that is already installed in Mac OS X even though could be not so simple to install it as daemon.
My advice is to go with objective-C or plain C ...
However if you are accustomed to working with .NET you can install mono and use mono-service to run the service as a daemon even on OS X, but in this case users will must install mono on their machine, so if you can deal with this trade off could be a viable solutions .
I'm looking for advice on good options to deploy Java applications on end user systems.
Our end users are not tech savvy experts but casual computer users who can't be expected to figure out directories and version conflicts.
Runnable jar is not practical because we need to provide VM parameters. Batch files are not practical because for whatever reason, java.exe is not on the $PATH in a huge amount of Windows system.
Webstart is an option, but our users commonly complain that no shortcuts are created (a feature that's apparently broken), every click on the website prompts a new download, and a plethora of other issues make this option seem incredibly unprofessional to the end user.
Many of the things one finds when googleing for Java deployments are themselves built with Java, which means they won't run either on a system with a missing or broken Java installation.
If you do not want to spend any money, a popular solution is izpack.
If you're looking for a commercially supported solution, there is install4j (Disclaimer: My company develops install4j). The installer is a Java application here as well. However, it is started by a native launcher that can download a JRE bundle from your server on the fly. You can also statically bundle a private JRE. See here for more information on JRE bundles.
Webstart is an option, but our users commonly complain that no shortcuts are created (a feature that's apparently broken), every click on the website prompts a new download, and a plethora of other issues make this option seem incredibly unprofessional to the end user.
Many webstart deployments are quite unprofessional. Make sure any deployment that is showing problems is validated using JaNeLA. For the shortcuts specifically, look into the IntegrationService of the JNLP API for establishing them after launch, with feed-back.
Ultimately though, APIs will have bugs. If you find one in web start, please report it on the bug database (v. broken at the moment, but you have to try).
Many of the things one finds when googleing for Java deployments are themselves built with Java, which means they won't run either on a system with a missing or broken Java installation.
As to missing or too low version Java, use deployJava.js to ensure a suitable JRE is present. No ideas on the broken installs.
I doubt you will swing back to JWS for this immediate deployment, but please investigate it according to the ideas outlined above, for future use.
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!