9 ms·

Java distribution is one of the biggest pains I've experienced in my development career. In all its forms, whether than be an applet, a J2SE application or J2EE

by malanj 12y ago

Java distribution is one of the biggest pains I've experienced in my development career. In all its forms, whether than be an applet, a J2SE application or J2EE enterprise deployment it always seems to be 10x harder than it should be. Somehow the Java ecosystem manages to make it much harder than it could be. If Sun had brought out a tool in the late 90's as simple as Packr seems to be it could have made a huge difference in the popularity of Java.

BHSPitMonkey 12y ago
I doubt they would have been satisfied with the mechanism Packr uses. Packr distributes a static copy of a JVM with every build, which results in some less-than-desirable side effects: - The more apps you've obtained this way, the more copies of JVMs you have on your hard drive. - These per-app JVMs aren't getting patched when the mainline JRE does. In a lot of ways, this undermines the purpose of the way Java is structured. If you're going to be statically compiling your product, why not use a more suitable platform?
- deleted 12y ago
  [deleted]
- stingraycharles 12y ago
  So in essence you're saying that if I want the advantages of static linking, I shouldn't be using java? Isn't there a middle ground somewhere?
  - mbreese 12y ago
    You have the same advantages and disadvantages with static-linking in general. If you want an easily distributable application (non-enterprise), then I think something like this is a great middle ground. The biggest attack surface for Java is from the web, so that should limit the disadvantages of embedding a JVM. So long as you aren't using your embedded JVM to load external code, you should be okay.
    - BHSPitMonkey 12y ago
      The difference between this being that normally you're only linking specific libraries that you need, instead of an entire runtime and standard library. There's a lot of potential energy hiding in each of these packages.
- dleskov 12y ago
  Most of the Java security issues only affected applets, not standalone apps. And the larger and the more sophisticated a standalone app is, the less desirable is running it on the system-default JRE.
- chii 12y ago
  You can easily distribute the JRE, but also autodetect if there is an existing JRE installation, and use that instead. Packaging a jvm is the right move for consumer apps. It's lower friction for people downloading and using it, and harddrive space these days are dirt cheap.
  - BHSPitMonkey 12y ago
    In that case, why not just have your installer check if Java is installed, and install a shared JRE if it's not? This is the case with most .NET applications I've had to install on Windows.
hrjet 12y ago
This sort of installer should only be required for apps that require some native code and/or tight integration with the Desktop Environment. For most other purposes, a simple .jar or .jnlp file works fine.
- mbreese 12y ago
  Simple JARs and JNLP files have a very poor user experience. No one knows what to do with them. If you click a web-start link, your browser might start up your app, or download the jnlp file. If it just downloaded the file, you now have another few steps: 1) find the newest jnlp file, and 2) click it. Naked JAR files aren't much better. In order to best integrate with the OS, you will probably have some runtime-specific settings that you'd like to apply (such as memory, or GUI specific-settings). If you just distribute a JAR, that can't be easily set. For Linux and Mac (command-line only) I've gotten into the habit wrapping up a JAR in a shell script to make one single file to distribute. The shell script can set all of the JVM flags that I need, and it can be run just like any executable. This doesn't solve the problem of adding icons, or the like for GUIs, but for command-line programs, it works great.
  - electrum 12y ago
    > For Linux and Mac (command-line only) I've gotten into the habit wrapping up a JAR in a shell script There is a Maven plugin to do this: https://github.com/brianm/really-executable-jars-maven-plugin https://github.com/brianm/really-executable-jars-maven-plugi... We use it for things like the Presto CLI.
  - gizmo686 12y ago
    >For Linux and Mac (command-line only) Why is this specific to Linux/Mac and command line. Windows has .bat files which can accomplish the same goal, and every filemanager I have used will recognize a script file and execute it when you try opening it.
    - krakensden 12y ago
      Can you do the trick where the actual binary is embedded in the .sh with batch files? I think that's what he's talking about.
eranation 12y ago
I completely agree, and I think if someone is looking for startup ideas, than Java EE one click distribution to WebLogic, WebSphere, JBoss clusters will be really worth the while. There is a huge enterprise market that is not ready yet to fully go to the cloud, or has their own "local" clouds (banking, insurance). The only solution I found till now that is remotely in the direction for Java EE is Cargo (http://cargo.codehaus.org/ http://cargo.codehaus.org/) but it seems to be more directed toward integration testing automation than deployment automation. Puppet was my hope but it is not even trying to be Java / JEE friendly from what I've seen. Oracle need to define a very opinionated, standard method of deploying, starting and stopping Java EE servers (JMX doesn't cut it yet) and IBM, and other vendors should comply, because eventually banks will ditch WebSphere / WebLogic toward things like Akka, Spary, DropWizard, TomEE etc. and IBM and Oracle will have nothing left to sell.
- deleted 12y ago
  [deleted]
- emmelaich 12y ago
  I wonder if you've tried http://www.smartfrog.org/ http://www.smartfrog.org/ ? I haven't; but it's been around for a while and seems to be fairly well used judging by the mailing list archives. "SmartFrog is a powerful and flexible Java-based software framework for configuring, deploying and managing distributed software systems."
bananas 12y ago
A couple of days spent trying to use WiX to build something that bootstraps .Net, VSTO and works on all windows platforms will make Java packaging look like bliss. To be honest if you respect the deployment conventions in java (i.e. think about them whilst building your product rather than retrospectively apply them) it's pretty easy.
- tonyedgecombe 12y ago
  Wix is horrid, if you don't need msi take a look at Inno Setup.
  - bananas 12y ago
    Everyone needs MSI eventually. It's the only thing that works properly with SCCM / MOM and you WILL end up with some corporate deployment that requests an MSI. As for WiX and MSI, it throws out bundles as well (.exe containing MSI bootstrapper) if you want to do anything complicated which means you're up shit creek anyway.
    - tonyedgecombe 12y ago
      I don't think so, Inno Setup supports silent installs, this has never been a deal breaker for me.
pjmlp 12y ago
With Java 7 onwards there is a packager as part of the standard JDK as well. http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm http://docs.oracle.com/javafx/2/deployment/self-contained-pa... Don't let the JavaFX references fool you, it is also applicable for other types of desktop applications. Sadly, the stripped implementations was dropped in Java 8, but might came back in later versions. All in all, I agree with you. Sun never knew how to do desktop development properly, projects like JDIC and JAI were left to rotten and deployment with scripts was always a second class deployment. They never understood what desktop developers and users what of their systems, letting the field open to .NET and frameworks like Qt/wxWidgets.
deleted 12y ago
[deleted]
StevePerkins 12y ago
Are you serious? Easy deployment is the primary thing to LIKE about Java, much more so than the actual language. In the Java world, your application dependencies are managed at the (gasp!) application level. You run Maven, Gradle, or whatever... and get a self-contained web archive (i.e. WAR file), with all of the application dependencies bundled. It's just a plain ZIP file, with a standard directory layout. With a light app server such as Tomcat or Jetty, you literally just drop that file into a particular directory, and it's deployed! You just delete the file (and any contents that the app server unzipped), and it's undeployed! If it's a console or GUI application rather than a web app, then you just create a JAR file in similar fashion. Maven has its "shade" plugin, and all of the other build systems have similar counterparts... which will bundle up all of the application's dependencies into the JAR file as well. You then ship that monolithic JAR file anywhere, just as you would a ".exe" file. Assuming that you declared a main class when you built the JAR, you can execute it on any system by typing "java -jar file_name.jar"... or by simply double-clicking it in a desktop environment. Whenever I've dabbled with Python, Ruby, or NodeJS... I've been STUNNED to learn that they follow the ancient Perl convention, of managing application dependencies at the global interpreter level. If I want to write two applications with conflicting sets of dependencies, then I have use a tool such as "virtualenv" (or its Ruby equivalent), to trick my environment into thinking that it's running in a completely different interpreter. NodeJS is somewhat more sane, in that "npm" supports local and global dependencies... but you still have to ensure that you haven't installed a dependency in the wrong place, and that your target machine will have what you need in the correct place. The current state of distribution and deployment for "dynamic" languages is so insane, that people are actually excited about the idea of shipping an ENTIRE CHROOT JAIL as a deployment unit (i.e. Docker). People are using that in production environments, even though the Docker devs themselves tell you that it's not ready for that yet, because in half-baked form it's still better than the traditional options. Java has many drawbacks, but distribution and deployment are NOT among them. Most of the people who upvoted this probably just reject Java as old and stuffy, and have not actually done significant work with it. If they had, then there might be at least one comment on this thread pointing out that Packr is a clone of Launch4j (http://launch4j.sourceforge.net http://launch4j.sourceforge.net)... which has been around for almost a decade now.
- 12y ago
kelseyfrancis 12y ago
> In all its forms, ... or J2EE enterprise deployment it always seems to be 10x harder than it should be. I might agree about desktop apps (the problem OP is trying to solve), but building a WAR or EAR and dropping it in a directory to deploy a webapp is about as easy as it gets. All dependencies are usually in the WAR (which is just a zip file, really), and it can usually be deployed to any servlet container or app server (including cloud offerings like Elastic Beanstalk) and work exactly as it did on your local box.

by malanj 12y ago

BHSPitMonkey 12y ago

I doubt they would have been satisfied with the mechanism Packr uses. Packr distributes a static copy of a JVM with every build, which results in some less-than-desirable side effects: - The more apps you've obtained this way, the more copies of JVMs you have on your hard drive. - These per-app JVMs aren't getting patched when the mainline JRE does. In a lot of ways, this undermines the purpose of the way Java is structured. If you're going to be statically compiling your product, why not use a more suitable platform?

deleted 12y ago
[deleted]
stingraycharles 12y ago
So in essence you're saying that if I want the advantages of static linking, I shouldn't be using java? Isn't there a middle ground somewhere?
- mbreese 12y ago
  You have the same advantages and disadvantages with static-linking in general. If you want an easily distributable application (non-enterprise), then I think something like this is a great middle ground. The biggest attack surface for Java is from the web, so that should limit the disadvantages of embedding a JVM. So long as you aren't using your embedded JVM to load external code, you should be okay.
  - BHSPitMonkey 12y ago
    The difference between this being that normally you're only linking specific libraries that you need, instead of an entire runtime and standard library. There's a lot of potential energy hiding in each of these packages.
dleskov 12y ago
Most of the Java security issues only affected applets, not standalone apps. And the larger and the more sophisticated a standalone app is, the less desirable is running it on the system-default JRE.
chii 12y ago
You can easily distribute the JRE, but also autodetect if there is an existing JRE installation, and use that instead. Packaging a jvm is the right move for consumer apps. It's lower friction for people downloading and using it, and harddrive space these days are dirt cheap.
- BHSPitMonkey 12y ago
  In that case, why not just have your installer check if Java is installed, and install a shared JRE if it's not? This is the case with most .NET applications I've had to install on Windows.

hrjet 12y ago

This sort of installer should only be required for apps that require some native code and/or tight integration with the Desktop Environment. For most other purposes, a simple .jar or .jnlp file works fine.

mbreese 12y ago
Simple JARs and JNLP files have a very poor user experience. No one knows what to do with them. If you click a web-start link, your browser might start up your app, or download the jnlp file. If it just downloaded the file, you now have another few steps: 1) find the newest jnlp file, and 2) click it. Naked JAR files aren't much better. In order to best integrate with the OS, you will probably have some runtime-specific settings that you'd like to apply (such as memory, or GUI specific-settings). If you just distribute a JAR, that can't be easily set. For Linux and Mac (command-line only) I've gotten into the habit wrapping up a JAR in a shell script to make one single file to distribute. The shell script can set all of the JVM flags that I need, and it can be run just like any executable. This doesn't solve the problem of adding icons, or the like for GUIs, but for command-line programs, it works great.
- electrum 12y ago
  > For Linux and Mac (command-line only) I've gotten into the habit wrapping up a JAR in a shell script There is a Maven plugin to do this: https://github.com/brianm/really-executable-jars-maven-plugin https://github.com/brianm/really-executable-jars-maven-plugi... We use it for things like the Presto CLI.
- gizmo686 12y ago
  >For Linux and Mac (command-line only) Why is this specific to Linux/Mac and command line. Windows has .bat files which can accomplish the same goal, and every filemanager I have used will recognize a script file and execute it when you try opening it.
  - krakensden 12y ago
    Can you do the trick where the actual binary is embedded in the .sh with batch files? I think that's what he's talking about.

eranation 12y ago

I completely agree, and I think if someone is looking for startup ideas, than Java EE one click distribution to WebLogic, WebSphere, JBoss clusters will be really worth the while. There is a huge enterprise market that is not ready yet to fully go to the cloud, or has their own "local" clouds (banking, insurance). The only solution I found till now that is remotely in the direction for Java EE is Cargo (http://cargo.codehaus.org/ http://cargo.codehaus.org/) but it seems to be more directed toward integration testing automation than deployment automation. Puppet was my hope but it is not even trying to be Java / JEE friendly from what I've seen. Oracle need to define a very opinionated, standard method of deploying, starting and stopping Java EE servers (JMX doesn't cut it yet) and IBM, and other vendors should comply, because eventually banks will ditch WebSphere / WebLogic toward things like Akka, Spary, DropWizard, TomEE etc. and IBM and Oracle will have nothing left to sell.

deleted 12y ago
[deleted]
emmelaich 12y ago
I wonder if you've tried http://www.smartfrog.org/ http://www.smartfrog.org/ ? I haven't; but it's been around for a while and seems to be fairly well used judging by the mailing list archives. "SmartFrog is a powerful and flexible Java-based software framework for configuring, deploying and managing distributed software systems."

bananas 12y ago

A couple of days spent trying to use WiX to build something that bootstraps .Net, VSTO and works on all windows platforms will make Java packaging look like bliss. To be honest if you respect the deployment conventions in java (i.e. think about them whilst building your product rather than retrospectively apply them) it's pretty easy.

tonyedgecombe 12y ago
Wix is horrid, if you don't need msi take a look at Inno Setup.
- bananas 12y ago
  Everyone needs MSI eventually. It's the only thing that works properly with SCCM / MOM and you WILL end up with some corporate deployment that requests an MSI. As for WiX and MSI, it throws out bundles as well (.exe containing MSI bootstrapper) if you want to do anything complicated which means you're up shit creek anyway.
  - tonyedgecombe 12y ago
    I don't think so, Inno Setup supports silent installs, this has never been a deal breaker for me.

pjmlp 12y ago

With Java 7 onwards there is a packager as part of the standard JDK as well. http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm http://docs.oracle.com/javafx/2/deployment/self-contained-pa... Don't let the JavaFX references fool you, it is also applicable for other types of desktop applications. Sadly, the stripped implementations was dropped in Java 8, but might came back in later versions. All in all, I agree with you. Sun never knew how to do desktop development properly, projects like JDIC and JAI were left to rotten and deployment with scripts was always a second class deployment. They never understood what desktop developers and users what of their systems, letting the field open to .NET and frameworks like Qt/wxWidgets.

deleted 12y ago

[deleted]

StevePerkins 12y ago

Are you serious? Easy deployment is the primary thing to LIKE about Java, much more so than the actual language. In the Java world, your application dependencies are managed at the (gasp!) application level. You run Maven, Gradle, or whatever... and get a self-contained web archive (i.e. WAR file), with all of the application dependencies bundled. It's just a plain ZIP file, with a standard directory layout. With a light app server such as Tomcat or Jetty, you literally just drop that file into a particular directory, and it's deployed! You just delete the file (and any contents that the app server unzipped), and it's undeployed! If it's a console or GUI application rather than a web app, then you just create a JAR file in similar fashion. Maven has its "shade" plugin, and all of the other build systems have similar counterparts... which will bundle up all of the application's dependencies into the JAR file as well. You then ship that monolithic JAR file anywhere, just as you would a ".exe" file. Assuming that you declared a main class when you built the JAR, you can execute it on any system by typing "java -jar file_name.jar"... or by simply double-clicking it in a desktop environment. Whenever I've dabbled with Python, Ruby, or NodeJS... I've been STUNNED to learn that they follow the ancient Perl convention, of managing application dependencies at the global interpreter level. If I want to write two applications with conflicting sets of dependencies, then I have use a tool such as "virtualenv" (or its Ruby equivalent), to trick my environment into thinking that it's running in a completely different interpreter. NodeJS is somewhat more sane, in that "npm" supports local and global dependencies... but you still have to ensure that you haven't installed a dependency in the wrong place, and that your target machine will have what you need in the correct place. The current state of distribution and deployment for "dynamic" languages is so insane, that people are actually excited about the idea of shipping an ENTIRE CHROOT JAIL as a deployment unit (i.e. Docker). People are using that in production environments, even though the Docker devs themselves tell you that it's not ready for that yet, because in half-baked form it's still better than the traditional options. Java has many drawbacks, but distribution and deployment are NOT among them. Most of the people who upvoted this probably just reject Java as old and stuffy, and have not actually done significant work with it. If they had, then there might be at least one comment on this thread pointing out that Packr is a clone of Launch4j (http://launch4j.sourceforge.net http://launch4j.sourceforge.net)... which has been around for almost a decade now.

12y ago

kelseyfrancis 12y ago

> In all its forms, ... or J2EE enterprise deployment it always seems to be 10x harder than it should be. I might agree about desktop apps (the problem OP is trying to solve), but building a WAR or EAR and dropping it in a directory to deploy a webapp is about as easy as it gets. All dependencies are usually in the WAR (which is just a zip file, really), and it can usually be deployed to any servlet container or app server (including cloud offerings like Elastic Beanstalk) and work exactly as it did on your local box.