'Nuther Java concern: Standalone application?

Bear with me, I think this is close to being the last of my Java programming problems.

The project I’ve been working on has been developed in the Netbeans environment. It works well for me as long as I don’t have to read the documentation much (it’s that intuitive).

I’m now to the point that my project needs to run outside of the IDE for testing purposes, but I cannot get that to happen.

I build the project using Build->Clean and Build Main Project

I run/debug using the Run->Run File option(s). Run Main Project and Debug Main Project does not work.

I went through the Netbeans Help stuff about building standalone projects, and it gave a driveby discussion on the topic. It mentioned editing the Ant script, and I took a look. I had no clue what I was looking for, or what I should change any of the values to.


In Netbeans, you want to edit the build.xml file to accomplish stuff like this. Some of it will be handled automatically, but you usually wind up tweaking that file. It’s an ant script, and the commentary in the file makes it pretty clear which rules you want to mess with. The downside is that you have to learn ant. Ant is basically an XML driven make utility, and messing with ant scripts is about the same level of complexity as messing with makefiles.

To get your project to run inside the IDE, right on the project, choose properties, select “run”, and you can fill in the main class, which will correspond to the java main you’ve been running directly. It also lets you fill in the expected stuff like starting directory, arguments, etc.

It helps to understand what is really needed for the standalone environment. What makes your project .jar file a standalone executable (other than containing all the needed class files and resources) is a single line in the manifest pointing to the main class - something like:

Main-Class: mypackage.MyMainClass

When you invoke “java [options] -jar myjar.jar [arguments]”, it starts up the jvm, instantiates that class, looks for a main method in it with the expected signature, and kicks it off, feeding it [arguments].

There’s lot of stuff that can be done in the manifest file. It’s worth doing some research on.

If you don’t want to get Netbeans to create the right manifest, you can actually simply extract the manifest file, diddle with it, and put it back in the jar. Jar files are actually zip files, so you can fiddle with them using your zip utility, provided you don’t screw up the expected structure or the manifest file. SIGNED jars are another story, but we needn’t go into that here.

I wish I could give you the quick magic answer to get you going in your current bind…

I don’t use Netbeans, so I can’t. Listen to yabob.

Anyway, I prefer to have our Java applications be buildable from Ant alone. That way, in five years when we suddenly need to patch a production app that no one knows how to build, much less how to install the ancient IDE that was used for it, we will still be able to build the app.

Most of your issues will be related to the classpath.
Often an IDE maintains its own concept of a classpath (JBuilder has “libraries” that you can configure) that is not known to Ant. The tool will often include its own secret classpath into Ant’s classpath when executing Ant. That’s not the same as having Ant set up to build everything standalone.

Basically, your build.xml file will need to set up its own classpaths in order for you to compile the app or execute from within Ant.

If you wish to run from the command line, you will end up either repackaging all of the jars for your project (e.g. Oracle JDBC drivers) along with your own class files into a single fat jar, done within Ant, or you will have to make sure your classpath includes each jar.

BTW, resources/files accessed from the filesystem will bite you in the butt if you jar things up. If your app gets icons from files, you will have to load them as resources.

Another thought: Your app will not be an “executable” unless you use a tool like Launch4j to wrap it up.

If you have lots of Java in your future, it will be well worth your time to get to know Ant very well.

Re classpath:

The classpath would, of course, be included with the [options] on the java command line I mentioned. As noted, if you create an executable or a shell script as a launcher you can hide this stuff. Indeed, one of the things you have to work out for deploying a java app is what other jars are required, and a commercial application will usually have its installer create a launcher. Particularly since a commercial app will usually want to distribute SEVERAL jars, as well as possibly allowing the user to specify the locations of supporting library jars, or local additions. In a Windows environment, you might want to make your launcher not create a console window so that you don’t have an irrelevent window floating around.

I’m gathering that the OP has a fairly simple app which uses only the normal java runtime. Packaging such an app in a jar, and invoking it as java -jar … probably serves a decent learning exercise at this point.

In the windows environment, the java installation often installs a rule for the “.jar” extension so that the user perceives it as “an executable”, and, in fact calls the thing an “executable jar file”. Of course, it still doesn’t work if the jar doesn’t point to a “Main-Class” in the manifest, or requires extra class path.

I will agree that in a commercial setting, you want a build procedure which is divorced from the development tools. Often this will be an RPM organization which takes delivery of source files, and builds from scratch, using the official “clean” procedures. QA then gets the “official” image to test with, a nobody relies on the nasty jury rigs that the developers usually use because they have their favorite tools and environments.

It is a rather simple app; a virtual control panel for some equipment I maintain. In the grand scheme of things, maybe a half dozen people will ever use it.

The app has no net access, so all of the resources are meant to be self contained.

I inherited the thing half written from the guy I replaced. Had I started it myself, it would be a C++ Windoze app, something I know how to do very well. Java is an OK language, but it’s not very well suited for something like this, and I’ve had to learn it and Netbeans on the fly, hence all of the questions.

I’ve been looking into the classpath as suggested, but I haven’t developed enough understanding to know what I’m looking at (yet).

If you haven’t added any libraries in Netbeans, It shouldn’t require a classpath. Look under the “Libraries” node under your project in the project view. If the only thing listed is “JDK blah-blah …”, it should run without any classpath specification, as it is not using any extra jars to run unless somebody fiddled with the default classpath used by Netbeans for all projects. Your only concern is that the standalone JRE is a suitable version to match “blah-blah”.

Classpath isn’t a terribly difficult concept anyway, just a niggling headache for deployment, like a lot of these things. The java command takes a option called “classpath”, eg:

java -classpath Some.jar;SomeOther.jar;SomeDirectory …

This just tells java where to look for extra class and resource definitions. You mentioned windows, so I used the ‘;’ character as the separator. The elements of the path may be jars, or they may be directories. The expected structure in the directory will be identical to that in the jar file - class baz.faz.Fiddle will be stored as a “Fiddle.class” file in directory “baz/faz”.

(BTW, one of the features of java which makes it very nice for certain types of applications is that you can define your own ClassLoader which obtains class definitions and resources in some other manner - you could store them as blobs in a DB, for instance. My description corresponds to the default system loader.)

If I happen to miss a JAR when noodling with a classpath, is there some kind of diagnostic available telling me that I’m missing either the JAR itself, or a component?

AFAIK the only external JAR I have to deal with is RXTX; so I should have that one covered. I’m trying to anticipate the unexpected…

You’ll get ClassNotFound exceptions.

Since you are just dipping your toe into Java, let me warn you: Do not “swallow” exceptions anywhere in your code. Make sure every exception is reported somehow and acted on (unless it is clear that the exception is never a concern).

The reason I say this is because the “ClassNotFound” exception is just the kind of thing that might be very difficult to spot if your code silently does this:

// Don't do this!
}catch(Throwable t){
  t.printStackTrace(); // this doesn't help much if a console isn't open.
// Nobody will ever know about the exception!

Once you figure out that you are missing a class, you can simply do a Windows “search” for files that contain the string “MyMissingClassName”. The offending jar will be found.

I would recommend dumping the IDE and making your own makefile. At heart, all you need is to call

javac filename.java

to get your .class files, and then the jar utility to create a .jar. You will need a manifest file in your jar, but essentially you just need to define the Main-Class parameter.

Either that or learn ant. (Or just write a shell script or batch file if you don’t know make.)