This is a case of not quite knowing enough to know what I don't know. I'll also be reading the oracle descriptions about imports and .jars, but it's rather dense and most of it doesn't seem applicable, so I thought multitasking would be a good answer; I can put this here and hope human expertise is able to direct me more rapidly than my scrolling through dry webpages in search of wisdom. I will, of course, still be reading up in the meantime; obviously I need to learn this stuff.
I'm using JDeveloper 18.104.22.168.1. This code has gone through three iterations, environments, and programmers; I'm not sure whether that's pertinent, but just in case...
I'm making a small game. One of the parameters one can set in the starting screen is to operate a remote device (through an ADU card) whenever one scores.
It uses the javax.comm package to do so. In project properties in JDeveloper, I have comm.jar set to import, and when I dissect Game.jar, it contains comm.jar.
It runs fine as far as the first screen of the program, in which one selects program variables.
However, if I select the remote device to operate, and click "Start" to advance to the game, it doesn't respond. Not a hard crash, because I can still change variables, and even set the remote device to "off" and it will advance to the game. For further confusion, when I run it from within the JDeveloper environment, it will run with the remote device selected and the game runs fine and the remote device turns on.
Running java -jar Game.jar from the command line, when I select remote device and hit start, it throws the following error message:
... and about 50 more lines.
I've tried putting copies of comm.jar in the JRE's bin and lib folders where I hoped it would see it, I've checked to make sure it's inside Game.jar, I'm just... baffled. My intuition is that JDeveloper somehow isn't including comm.jar correctly in Game.jar, but I still don't know enough to be sure.
What else do you need? Where should I look?
And a less urgent additional question:
The program also uses two .dlls to operate. We've been dropping copies of them into Program Files/Java/jre(whatever the latest is)/bin every time we bring the jar to a new computer, which is semi-acceptable, but I was wondering if there's a way to bundle them within the .jar such that it would see them and I wouldn't have to instruct the user where to put the .dlls. For one thing, there's a small level of confusion since the jre doesn't always have the same number or location. For the second, the users sometimes get confused or lie about whether they've put the .dlls in the right place.
For the first part, what happens if you build it outside the IDE? Do you have an Ant or Maven script that can build it? Personally, I never rely on an IDE to build anything for me. IDEs are fine for editing, but when it comes time to build either Ant or Maven is the way to go.
For the second part, you should create an installation package for your app. That package can ensure that a JRE is installed (there are registry entries you can query), and can place the DLLs in the PATH (I recommend placing the DLLs with your JARs and adding that directory to the PATH).
One of the ways to tell the difference between Java professionals and cheap labor is that a professional can - and frequently does - use an IDE to help create and debug software, but cheap labor is unable to function without an IDE. And generally a set of IDE wizards.
Needless to say, if you don't understand what you're doing well enough to do it yourself, you're likely to produce some really horrible results.
Making a JAR something you do in preparation for deployment. Many IDEs have little or no support for that end, since complex deployments require complex tools, and it's much more economical for them to pass the job on to ready-made build tools like Ant and Maven. Also, I can attest from personal experience that command-line based builds less idiosyncratic and less likely to break when the IDE goes to newer releases. And, finally, in a few cases, I've done my production builds on "headless" machines, where there was no GUI at all (GUIS are expensive resources compared to non-GUI platforms), so a command-line build was the only option.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Oct 14, 2005
Oh dear... I probably qualify as a cheap labor hacker at this point. When last I did my own canning, dinosaurs ruled the earth, and I definitely haven't been staying in touch with the language.
I'll re-familiarize myself with the jar process and try it out tomorrow morning. Thanks for the brains!
Well, we're here to help the amateurgrammers become "pro-"grammers.
Making a jar is easy, though. The jar utility is just another ZIP program that happens to support those little extra things like manifests.
Building Enterprise applications, however, has gotten a little more complicated over the years as more and more power features have become "must-have". So check out the Ant and Maven build tools. They can run the jar utility and do much more besides, giving you a "one-button" tool for assembling complex apps and doing it a lot more intelligently than something like Windows batch files would.
Joined: Oct 14, 2005
Found it! Inspired by Joanne Neal's brains on another question:
That problem was because my main class (part of a package) was at Game.jar/main.class rather than Game.jar/package/main.class.
I extrapolated that it might also be having problems finding pieces of the comm.jar because I hadn't unpacked it to Game.jar/javax/comm/(comm class files). Doing so, and re-jarring it with that directory structure, made the game able to find the remote device outside of the IDE.
I'm not sure what changed in JDeveloper's deployment options such that it doesn't seem to be including comm.jar, but as long as manual manipulation results in a working product, I'm happy .
In the meantime, I'll poke at JDeveloper a bit to see if I can get it to start including required .jars as well, so I won't have to remember to paste in these classes next time.
For more happy results, another (less-important, but still useful) function dependent on an external .jar stopped working a while back, and it stands to reason that this could be the same cause.