I understand that StackOverflow is geared towards answering specific questions and avoiding subjective opinion. I feel that my question(s) have only one correct answer and therefore I’m posting here.
I’ve created a Java desktop app (JavaFX) which I plan to distribute for commercial use. I’ve read that Java code is easily reverse-engineered so it’s critical to obfuscate using something like ProGuard. I’d like to package my app so that users double click a .exe (which they download from my site) and then an installer is run like any standard software does. This appears to be outside the scope of ProGuard, but I’ve found JWrapper and Launch4J which both seem to provide similar functionality. Both claim to wrap jars into Windows native executables, show splash screens, include JRE, but I'm confused where they differ.
Specifically, I need the following:
Installation Wizard (namely to place the exe somewhere safe + make shortcut on desktop, and also add the EULA somewhere).
Add EULA (End-User License Agreement) which specifies user’s limitations
Web updates for the app (JWrapper seems to provide this using URL + build path)
Ability to protect the app (somewhat) using licensing (License3j seems promising).
Their features can be found here and here but only JWrapper mentions the ability to perform web updates and mentions desktop shortcuts (which I assume can also write a EULA.txt somewhere).
So, after I have finished writing code, in which order should ProGuard, JWrapper and Launch4j be applied? I’m guessing ProGuard first (to shrink, optimize and obfuscate) and then JWrapper and then Launch4j? Or only 2 of 3?
Feel free to also suggest additional methods, tools, or concepts which I may be missing. Thank you!
This question seems out of scope for Stackoverflow, but to answer it:
apply ProGuard first on your application, keeping the main method of your application
apply either launch4j or jwrapper (up to you to choose) on the jar processed by ProGuard
Related
I have a Java application that I am considering releasing over the web as an applet. I am concerned about java-savvy end users being able to somehow view the source code, given that my web server would be sending the code to their remote jvm when they try to use the applet.
What precautions can be taken to ensure that end users are never able to directly view source code of an applet?
I am hoping that release as an applet might somehow protect the privacy of the code more than releasing an application with downloadable jars that the user could just unzip. Is this true?
As a Jar is essentially just a zip file in disguise there's not really a way to keep people from viewing the source code. There are lots of decompilers available for Java classes. Most developers that are concerned about end-users decompiling the source code use an obfuscater to make the code more or less unreadable or at least difficult to understand.
Sorry there is not really a good answer to the question, it is just the nature of the Java language that you can always decompile the source code.
There are options like wrapping a Java application in an executable that will make it more difficult to access the Jar itself but obviously you can't do this for an applet.
Here's a (company) blog post on the topic of converting Java to an executable:
http://www.excelsior-usa.com/articles/java-to-exe.html
Pulled from an SO thread also on the topic:
How can I convert a JAR file to an EXE file?
You could use some of the available open-source code obfuscators (many people recommend using ProGuard, not only for obfuscating but also code minimization).
If somebody really wants your code, they'll get it. The best you can do is try to make it more difficult. As others have stated, a typical approach is to use a code obfuscator.
If you're using Maven to build your project you can use the proguard-maven-plugin from the maven central repository.
But since you're considering releasing it as an applet, if you can have any functionality running on server side code, you can go a lot farther towards securing your code base.
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.
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/
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 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!