How do I make an executable?

[Jim Venolia]

I've got my java working nicely, I can run it via java -jar Program.jar arguments.  But I need to have Program.jar in the current directory, plus it's a lot of typing.

How can I put Program somewhere in my path (not classpath) so I can just "program arguments"?

[Carey Brown]

Most operating systems support batch files or scripts that simplify execution.

On Windows:

File:
Program.bat

Contents:
java -jar Program.jar %*

[Jim Venolia]

That's not what I asked.  A big concern is the proliferation of Program.jar files.  As a minimum I should be able to pop one somewhere, then say "java -jar /somewhere/Program.jar arguments", but if the jar file isn't in the current directory it doesn't run right.  I'm guessing classpath issues, but whatever.

I want to be able to fix a bug. pop the something somewhere convenient, and just run it.  As it is I have 4-5 bloody Program.jar files sprinkled around.  Fixing bugs is easy.  Finding and updating all these stupid .jar files is a pain in the patoot.

I don't want a batch file.  I don't want a shell script.  I don't want an alias.  I want a self contained executable.

[Norm Radder]

pop the something somewhere convenient, and just run it.

I can do that with a jar file.  I can put them anywhere, double click them and they execute.

if the jar file isn't in the current directory it doesn't run right

Please explain and give an example.

What about an .exe file that is not in the current directory? How do you get it to run without telling the OS where it is located?

[Jim Venolia]

If you double click it how do you feed it arguments?  Guess I could change it to open a window where I choose arguments but, jeez, why would I need to do that?

As for examples, that's hard.  You would need to know the input file format and the expected output.  Suffice to say, "java -jar Foo.jar arguments" gives different results than "java -jar /tmp/Foo.jar arguments".  I've tried -cp instead of -jar, no joy.  I've tried lots of things, no joy.  Now if that's a problem with my environment I'm happy to hear the solution.  Maybe add /tmp to classpath?  I dunno.  Hate to keep my executables in /tmp tho.

I have 2 big problems:

1)  "java -jar Foo.jar arguments" is both more typing than needed, and requires Foo.jar in the current directory.
2)  "java -jar /somedir/Foo.jar arguments" does not give the same results as the example above.

I'm running Cygwin under Windows10, if it matters.  But I sincerely hope not, seems my question is kinda Java 101.

[Norm Radder]

how do you feed it arguments?

How would you feed arguments to an executable?

To feed args to a program via the command line, there needs to be a command prompt window where the command line is built.

Otherwise why not have the program use JOptionPane to prompt for its args?

[Jim Venolia]

As it is I have Foo.jar in my current working directory, I type in "java -jar Foo.jar arguments" and it works.

If Foo.jar is in another directory I type "java -jar ../tools/Foo.jar arguments".  When I do this I get different (read: wrong) results.  Dits for "java -jar /path/to/foo/NetBeans/jar/file arguments".

JOptionPane?  Never heard of it.  I assume it lets me enter options.  Why would I want a window to pop up when I'm on a command line and just want an executable that I can run from anywhere?

Is this really so hard to understand?  When you say "dir" do you have to say "java -jar ./dir.jar", or do you just say dir?  Is it ok if you say "java -jar /some/path/dir.jar", and get different results than if dir.jar is in the current directory?

[Jim Venolia]

Ahhh, I get the disconnect.  I'm working from a command line.  Dos, PowerShell, csh, tcsh, doesn't matter.  No gui involved, anywhere.  The input is a text file.  The output is a text file.  The filter is a java .jar file.  The output goes into a text editor.

[Norm Radder]

I don't see how having an .exe file would solve the problem.

I'd think having the jar file on  a flash drive would allow you to plug in the drive, click on the jar file, type in the arguments would be the easiest solution.  No command prompt window, no command line.

want an executable that I can run from anywhere?

Yes a jar file fits that description.  The problem is passing the args. The JOptionPane class would solve that problem.

JOptionPane?  Never heard of it.

Do you program in java?  Look at the API doc:  http://docs.oracle.com/javase/8/docs/api/index.html

[Jim Venolia]

What about an .exe file that is not in the current directory? How do you get it to run without telling the OS where it is located?

I put it somewhere in my path.  That's exactly what I'm asking how to do.  I want an executable I can put in my path so it just works.

[Jim Venolia]

I'd think having the jar file on  a flash drive would allow you to plug in the drive, click on the jar file, type in the arguments would be the easiest solution.  No command prompt window, no command line.

So.

1)  Insert flash drive
2)  Enter a GUI
3)  Double click Foo.jar
4)  Enter arguments in the window that pops up
5)  voila

As opposed to

1)  It's Monday
2)  Foo logfile
3)  Scan logfile.out for issues.

Steps 1-3 should take maybe 20 seconds.

Yeah, I can see how your way is superior to what I want to do

I'm in a bad mood, I know this site values civility over all else, but, sigh.  I flat out don't understand why this is hard to understand.  

On the other hand, my Plex Library shuffle just chose Song Sung Blue, by Neil Diamond, so.  No.  I fail to understand how and why what I'm after is so difficult.  Even if my background music rocks.

[Ron McLeod]

Launch4j may work for you.  I have not used it myself, but I have used applications like the Arduino IDE which use it.

[Jim Venolia]

Launch4j may work, but what you're saying is there is no way to make a simple Jave .exe file I can put in my path?

That is, um, not good.   For me.  Everything I've written for the past 40 years has been a .exe, a .lib, or a Linux kernel module I could load.

[Ron McLeod]

Maybe you shouldn't be using Java for those types of applications.

[Jim Venolia]

That's the conclusion I'm coming to

3 years ago I wanted to learn OO, Java seemed the way to go.  But if Java won't produce a .exe then, well, I'm not gonna call it wasted, just misdirected.

[Norm Radder]

Can you explain how you would use an .exe file for your problem?  I can not see how it is any different from a jar file.

These three steps make no sense to me:

As opposed to

1)  It's Monday
2)  Foo logfile
3)  Scan logfile.out for issues.

[Ron McLeod]

Jim Venolia wrote:3 years ago I wanted to learn OO, Java seemed the way to go.  But if Java won't produce a .exe then, well, I'm not gonna call it wasted, just misdirected.

I don't see the connection between learning  OOD/OOP and producing .exe files, but if the end goal was to create Windows executables or Linux kernel modules, then C# or C++ might have been better choices.

[Ron McLeod]

Ron McLeod wrote:Launch4j may work for you.  I have not used it myself, but I have used applications like the Arduino IDE which use it.

Excelsior JET might be another option.  I believe that they have a non-cost license for personal use.

[Stephan van Hulst]

I don't understand why you want a .exe so badly, but a shell script is unwanted. That seems like an arbitrary decision.

It's also not clear why you have so many Program.jar files lying around.

I found I have very little need for .exe files. Just create a .lnk file that calls java with your jar, and specify the needed arguments and switches.

[yoel fisher]

simple use the fat jar maker:

http://ninjacave.com/jarsplice

you can create executable for linux and mac with the same java code.

the simplest sulution

[Tim Holloway]

Jim Venolia wrote:That's the conclusion I'm coming to

3 years ago I wanted to learn OO, Java seemed the way to go.  But if Java won't produce a .exe then, well, I'm not gonna call it wasted, just misdirected.

A lot of things don't produce .exe's these days. VMs are quite popular. Not only for Java, but for Python, Ruby, JavaScript, and many other languages. Some of which use Java's JVM, some of which implement their own VMs.

An .exe is no longer all that wonderful. I last booted Microsoft Windows on April 12th. Because the only app that I don't have a Linux equivalent for is TurboTax and I don't use the web-based version. In fact, a lot of the apps I do run aren't available on Windows. Some, like my servers I wouldn't consider running on Windows. Although Windows isn't quite the security nightmare it was for years, a lot of the best server and enterprise tools either don't run under Windows, or have limited functionality on Windows. Also, commercial Windows apps have a very annoying habit of chatting back over the Internet to their vendor. I prefer to keep my systems as private as possible.

JVM-based apps run unmodified on Windows, Linux, OSX, IBM zOS, and other platforms. An .exe file runs under Windows. Period. At best a Windows Emulator such as WINE, which is not Windows.

There are downsides, of course. In a task manager, instead of the application program name, you see the name "java". Oh wait. We're talking the OS where many apps appeared under the name "rundll32". A JVM is fairly large, so actually bundling it  into an executable costs disk space - not that anyone cares anymore. And since the JVM itself is copyrighted material, there are limits to how freely you can package it up in another app. So on the whole, it's generally better to require that the user have a separately-installed JVM.


A JAR can be self-executing under a JVM. All that's required is a simple statement in its manifest. It gets stickier if you need classpath resources from outside the JAR - database drivers, for example, but you can resolve that by setting up an environment and execution in a batch file. And Windows has supported double-click BAT launching since forever.

If you need non-classpath resources such as data files which are kept in the same directory as the Java app, that, too is a batchfile function. Just make the batch file "CD" into the application's directory. Or for that matter, whatever directory you want to work from.

[yoel fisher]

Tim Holloway is right.

i will say it simpler. if somone wants to use your softwere thy will install python and lua or what ever. they may even go throgh complex installations.
if your target users are programmers they wont be shay using cli with tools like grunt node.js etc etc.

now your judging a programming language on if it can create exe or not?

in the end of the day all programming languages have the same logic (machine logic). in the end its only tools and you use the one you need or like.
or whatever makes you money or brings results.

[Jim Venolia]

Sorry for not replying, I've been sick as a dog since I first asked the question.  Prolly why I was in a bad mood.

I think there is a misperception.  First, I don't want the entire Java engine in my .exe.  Second, a jar file sounds like just what I want.  Problem is, from a command line "java -jar foo.jar bar" gives a different result than "java -jar /some/dir/foo.jar bar" does.  No errors, but foo.jar is a bunch of regular expressions that parses a log file and I get different results calling it from a directory other than the current one.

Hoping to feel bettor tomorrow, then I'll try "cd /some/dir; java -jar foo.jar /some/other/dir/bar".  I'll also try to read this thread to see what I can see.

[Norm Radder]

I get different results calling it from a directory other than the current one.

What kind of location dependencies does it have?  What does the code in the jar file expect about the current directory and the jar file's location?

[Stephan van Hulst]

Aye, in that case the application works with files relative to the working directory. If that's not what you want you need to fix it to resolve paths against the executing jar's location:

import java.net.*;
import java.nio.file.*;

import org.slf4j.*;

public final class Application {

  private static final Logger LOGGER = LoggerFactory.getLogger(Application.class);

  private static final Path DIRECTORY;

  static {
    Path dir;

    try {
      URI location = Application.class.getProtectionDomain().getLocation().toURI();
      dir = Paths.get(location).getParent();
    }

    catch (
      URISyntaxException          |
      IllegalArgumentException    |
      FileSystemNotFoundException |
      SecurityException ex
    ) {
      LOGGER.warn("The location of the application could not be determined. Using current working directory instead.", ex);
      dir = Paths.get(".");
    }

    DIRECTORY = dir;
  }

  public static Path resolve(Path relative) {
    return DIRECTORY.resolve(relative);
  }
}

Then, instead of using relative paths in your application directly, for paths that refer to files in your application directory, just call Application.resolve(path) first.

[Jamy Spencer]

The whole design of Java is to make platform independent bytecode files (.jar) that can be run on any computer that has a JVM. This way you can compile your .jar on your microsoft system, email it to your friend who has a Mac and he can run it as long as he has the JVM installed on his Mac. That may not seem important to you in the context of your project but it is a major design consideration for other people which is why Java is such a common language.

My recommendation is to create a directory where you make batch programs that make your life easier at the command line, put that directory in your Path so it will get checked no matter which directory you are in. Then when writing the batch program fully qualify the location of your jar. Also if you are just doing a one off temporary project you can also just hit the up arrow to reenter the last command used.

One thing you need to realize as a programmer is that there are all kinds of tools that are available. They all have their strengths and weaknesses, its pointless to complain about your tools, you can either choose a different one, learn to use the current one better or design a new one. If you decide to learn a different one you will most likely find that you just really traded one set of things you didn't like for a different set of things you don't like.

Also if you are just doing a one off temporary project you can also just hit the up arrow to reenter the last command used.

[Jim Venolia]

Stephan van Hulst wrote:Aye, in that case the application works with files relative to the working directory. If that's not what you want you need to fix it to resolve paths against the executing jar's location:

I need to close this out.  Sounds like Stephan pointed me to the right solution.  Haven't been able to try it yet, but at least it leads me down the right path when (if) I ever get back to it.  It would have never occurred to me paths would be relative to the jar file location, instead of where I entered the command.  

As for making an executable, if that is what a jar is for (which I thought it was) then I'm good.  I can easily make an alias to point to a jar file $diety/knows/where, but my jar file evidently doesn't work like that.  I never expected an .exe containing the jre or whatever.

Rereading my quote of Stephan, sounds like jar files work how I thought.  But at least now I know what to look for.

Why it took so long to reply, and why haven't I tried Stephan's fix?  Lets just say July was not the favorite month of my life, and August wasn't much better.