 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2007Not too clear on the libraries available at run time
One of the fundamental problems with Java is that you double click on an executable jar... and nothing happens. Or perhaps the program does start but then it stops working, when you click on a button or menu. Compare with an *.exe file. You double click on it, and it works. My Java programs work beautifully when I start them from inside JBuilder, NetBeans or Eclipse. When I was a newbie, I made a decision: "let's just put every single needed library in the jar file". After all, my programs were simple and small at the time. In Unix, you just place any ancillary stuff (*.so or *.a) under /usr/ local and a lot of programs work properly. With Java (on Windows, BTW) where the hell am I supposed to place the third party jar libraries? My current application is based on OpenOffice. There are 4 indispensable files: - juh.jar - jurt.jar - ridl.jar - unoil.jar Eclipse doesn't seem to like my idea of stuffing those in the final executable jar. So, let's try placing them in the directory: C:\Program Files\Java\jre1.6.0_03\lib\ext Because I have a vague recollection (no book, no tutorial mentions this) that such place is special. I double click and... it doesn't work. I would like to send my application as an attachment to some friends. All I can guarantee is that they have Java in their Windows PCs. They will not mess around with their PATH. This simple fact that I am describing here must have turned a whole lot of people away from Java... -Ramon > One of the fundamental problems with Java is that you double click on > an executable jar... and nothing happens. Or perhaps the program does [quoted text clipped - 37 lines] > This simple fact that I am describing here must have turned a whole > lot of people away from Java... You put a Class-Path directive in the manifest of your jar file that points to the other jar files. It is documented. If you want to add them system wide, then lib/ext is the place, but not many Java apps want to use that method. Poor isolation between apps's different versions of the same libs. Arne > > One of the fundamental problems with Java is that you double click on > > an executable jar... and nothing happens. Or perhaps the program does [quoted text clipped - 48 lines] > > Arne This is what I did, Arne: Eclipse generated an executable jar for me. I changed the extension *.jar to *.zip, then decompressed it and added this line to the manifest: Class-Path: lib/juh.jar lib/jurt.jar lib/ridl.jar lib/unoil.jar I zipped the folder, and renamed it back to *.jar. When I double click, it says that the jar file is defective. -Ramon >>> One of the fundamental problems with Java is that you double click on >>> an executable jar... and nothing happens. Or perhaps the program does [quoted text clipped - 62 lines] > > -Ramon Most zip tools are incapable of generating a valid JAR file[0]. Use the command-line 'jar' tool instead: To expand a JAR file: jar xf foo.jar To compress a directory tree into a JAR file: jar cmf foo.jar MANIFEST-FILENAME path/to/root or without a manifest: jar cf foo.jar path/to/root -o [0] The JAR file spec imposes a few brain-damaged restrictions on the file's physical layout, which ZIP tools are unaware of. While every JAR is a valid ZIP, not every ZIP is a valid JAR. > Eclipse generated an executable jar for me. I changed the extension > *.jar to *.zip, then decompressed it and added this line to the [quoted text clipped - 5 lines] > > When I double click, it says that the jar file is defective. Create a text file in the project in Eclipse write the line to that and when you generate the jar file tell Eclipse to use that file as manifest. Arne >Eclipse generated an executable jar for me. I changed the extension >*.jar to *.zip, then decompressed it and added this line to the [quoted text clipped - 5 lines] > >When I double click, it says that the jar file is defective. Don't unzip the whole thing, just extract the manifest from the .zip file. Edit the manifest (with a unicode editor) and then update the .zip file and rename it to .jar again. I've done this lots of times with no problems. George -- for email reply remove "/" from address > On Sun, 2 Dec 2007 15:15:05 -0800 (PST), Ramon F Herrera > [quoted text clipped - 18 lines] > -- > for email reply remove "/" from address How do I update the .zip file without decompressing it? I am using the Windows-provided "send to compressed (zipped) folder". Anyway, I discovered what the problem was. I was creating one folder too many. If you select a folder and perform a 'send to zipped folder' an extra layer is added. What I do now it to select the contents of the folder only, not the "envelope". Thanks, -Ramon >... >How do I update the .zip .. The later Java runtimes will not check .zip files for code signatures. It is more reliable to use the .jar extension consistently. >.. file without decompressing it? .. <http://ant.apache.org/manual/CoreTasks/jar.html> See the 'update' parameter. >..I am using the Windows-provided ... That is bound to lead to grief. If not now, then at some point in the future. When dealing with Java builds, it is best to stick to core SDK tools, and Ant (which mostly invokes SDK tools). Also, manifest files are much more reliable when written by Ant. See the thread in which I posted this reply, for further details.. <http://groups.google.com/group/comp.lang.java.programmer/msg/a533efe8fb0519d3  SignatureAndrew Thompson http://www.physci.org/ > >... > >How do I update the .zip .. [quoted text clipped - 22 lines] > -- > Andrew Thompsonhttp://www.physci.org/ Thanks for the advice, Andrew! I will follow it. -Ramon >How do I update the .zip file without decompressing it? I am using the >Windows-provided "send to compressed (zipped) folder". Get a copy of Winzip - it can update files in place in the archive. If the update is larger than the original the file will be fragmented in the archive, but Sun Java doesn't seem to care (don't know about others). Winzip 11 is available from http://www.winzip.com. Older versions you can get from http://www.oldversion.com/program.php?n=winzip. Be aware that the latest stuff is commercial and the download a trial version. I still use Winzip 7 which is shareware and I've never encountered any zip archive that required a later version. I don't know at which version Winzip went commercial, but oldversion.com has them all so you can check them out if you are feeling adventurous. George -- for email reply remove "/" from address > One of the fundamental problems with Java is that you double click on > an executable jar... and nothing happens. Or perhaps the program does [quoted text clipped - 39 lines] > > -Ramon One alternative is to use WebStart. Find somewhere to host the files and then just send your friends a link. Mark Thornton > One of the fundamental problems with Java is that you double click on > an executable jar... and nothing happens. Or perhaps the program does [quoted text clipped - 39 lines] > > -Ramon "java.ext.dirs" is a list of directories that specifies the locations in which to search for extensions. By default two standard directories are listed. The first is the "jre/lib/ext" directory of the currently used JRE, and the second is a directory (a system-wide repository) outside of the JRE. This system-wide location allows extension JAR files to be installed once and used by all JREs installed on that system. The location varies depending on OS: Solaris: /usr/jdk/packages/lib/ext Linux: /usr/java/packages/lib/ext Windows: %SystemRoot%\Sun\Java\lib\ext (=C:\Windows\...) Copying jars into an ext directory is dangerous since updates to the source of the jars (OpenOffice in your case) won't automatically get copied. Using the per-JRE method at least makes you look at your jars again whenever the JRE is updated. (Of course, automatic updates are a "gotcha" in this case; your app one day just stops working!) Another danger is, by default installed packages in the system-wide repository are trusted (i.e. granted the same privileges as if they were core platform classes in rt.jar). It may be safer to create your own system-wide repository, and remember to list it each time. The best idea is to list the extra classes needed in your manifest file of your jar. These are called "optional classes" for some reason. See http://java.sun.com/docs/books/tutorial/deployment/jar/downman.html for details. Applets are another matter. You must put the optional jars at the same code base as the application and they get automatically downloaded. -Wayne > > One of the fundamental problems with Java is that you double click on > > an executable jar... and nothing happens. Or perhaps the program does [quoted text clipped - 50 lines] > Linux: /usr/java/packages/lib/ext > Windows: %SystemRoot%\Sun\Java\lib\ext (=C:\Windows\...) In my WinXP only this directory exists: C:\WINDOWS\Sun\Java\Deployment and it is empty. So, am I supposed to create lib\ and lib\ext ? Like I said, only God knows how many people have been turned away by such lack of libraries at run time. Is that what they call vaporware?? -Ramon >>> One of the fundamental problems with Java is that you double click on >>> an executable jar... and nothing happens. Or perhaps the program does [quoted text clipped - 49 lines] > > -Ramon Yep, those directories don't get created by default, at least on Windows. By default jars placed there are "trusted", so that directory should only be writable by the admin user. -Wayne >> "java.ext.dirs" is a list of directories that specifies the locations >> in which to search for extensions. By default two standard directories [quoted text clipped - 14 lines] > > So, am I supposed to create lib\ and lib\ext ? No, you should do what Wayne suggested. The usual solution - for applications is to distribute needed JARs with your application and refer to them in the manifest of your own JAR. - for applets is to mount the needed JARs in the same codebase whence comes your own JAR. - for Java WebStart apps is to use the JNLP file to specify where the needed JARs are. - for web apps is to mount the needed JARs in the <applicationContext>/WEB-INF/lib/ directory. Don't mess around with extensions directories. SignatureLew > Like I said, only God knows how many people have been turned away by > such lack of libraries at run time. Java is not that difficult to learn. But it is necessary to do an effort to learn it. Like reading Sun's tutorial or a book with similar content. Arne > One of the fundamental problems with Java is that you double click on > an executable jar... and nothing happens. Or perhaps the program does > start but then it stops working, when you click on a button or menu. > > Compare with an *.exe file. You double click on it, and it works. If you've done Windows development, think back to the idea of "DLLs distributed with your app" and keep that in mind while you read this post. > When I was a newbie, I made a decision: "let's just put every single > needed library in the jar file". After all, my programs were simple [quoted text clipped - 3 lines] > local and a lot of programs work properly. With Java (on Windows, BTW) > where the hell am I supposed to place the third party jar libraries? Traditionally, in parallel with your application. Your distribution would be a zip file containing foo-1.2/ foo-1.2/myapp.jar foo-1.2/lib/ foo-1.2/lib/dependency1.jar foo-1.2/lib/dependency2.jar (Other structures are, of course, equally valid.) The myapp.jar Class-Path manifest entry would refer to lib/dependency1.jar lib/dependency2.jar, which is sufficient for the runtime to locate the classes in those JARs. Manifests are explained on Sun's site: <http://java.sun.com/javase/6/docs/technotes/guides/jar/jar.html> > My current application is based on OpenOffice. There are 4 > indispensable files: [quoted text clipped - 3 lines] > - ridl.jar > - unoil.jar This, of course, relies on being permitted to distribute these JAR files. You'll have to check the OpenOffice license yourself; while I suspect you can distribute them, I'm not certain of that. If you can't distribute those JARs, then you're going to have a problem as their location is going to be different on every system your app runs on; solving that problem is non-trivial. > Eclipse doesn't seem to like my idea of stuffing those in the final > executable jar. So, let's try placing them in the directory: > > C:\Program Files\Java\jre1.6.0_03\lib\ext Please don't use global extensions. They're visible to every java program running under the same JRE, and if another program decides it needs a different version of the same classes then, unpredictably, either your version or his version will not be loaded. Keep your dependencies contained to the app that needs them. The CLASS_PATH environment variable suffers from the same problems. Roedy Green has an extremely good explanation of class path issues: <http://www.mindprod.com/jgloss/classpath.html> > I would like to send my application as an attachment to some friends. > All I can guarantee is that they have Java in their Windows PCs. They > will not mess around with their PATH. As Mark Thornton suggests, your best bet is likely Java Web Start, which lets you skip the jar Class-Path entries in favour of JWS' own "libraries" mechanism. This still relies on being allowed to distribute the JARs yourself, but it makes managing them and launching the program much easier. -o > Roedy Green has an extremely good explanation of class path issues: > <http://www.mindprod.com/jgloss/classpath.html> I agree with that. But it is missing one important gotcha: "To run JUnit tests, you'll need the following elements in CLASSPATH: * JUnit class files * Your class files, including your JUnit test classes * Libraries your class files depend on" JUnit requires use of CLASSPATH. It doesn't understand extension directories or other classloading methods. And don't forget that *all* of this discussion only applies when using the standard classloader. -Wayne >> Roedy Green has an extremely good explanation of class path issues: >> <http://www.mindprod.com/jgloss/classpath.html> [quoted text clipped - 11 lines] > And don't forget that *all* of this discussion only applies when > using the standard classloader. What ?? I have been running all kinds of JUnit tests over the years (primarily via ant scripts) and never put any of that in CLASSPATH. Normal classpath seems to work fine ! Arne On Sun, 2 Dec 2007 10:39:09 -0800 (PST), Ramon F Herrera <ramon@conexus.net> wrote, quoted or indirectly quoted someone who said : >One of the fundamental problems with Java is that you double click on >an executable jar... and nothing happens. Or perhaps the program does >start but then it stops working, when you click on a button or menu. > >Compare with an *.exe file. You double click on it, and it works. that is an operating system problem, and one that can be fixed, at least in Windows. You must set up the association. See http://mindprod.com/jgloss/jar.html SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > One of the fundamental problems with Java is that you double click on > an executable jar... and nothing happens. Or perhaps the program does [quoted text clipped - 37 lines] > This simple fact that I am describing here must have turned a whole > lot of people away from Java... You can (although not trivially) package all your libs with your app in one unique jar file. This is best done with the FatJar plugin if you use Eclipse. Also have a look at OneJAR: http://one-jar.sourceforge.net/ Phil I have written a Jar utility for the OSGi framework that is also handy in your case. You can easily merge all your dependencies in a single jar. Just create a bnd file (normal properties file): -output: myjar.jar -classpath: src, juh.jar, jurt.jar, ridl.jar, unoil.jar Export-Package: * Main-Class: com.acme.MyMain This way you only have to ship a single jar file. This will also make it an OSGi bundle but the extra headers can't harm. Bndis described at http://www.aQute.biz/Code/Bnd (and also in Chinese Code/BndCn!) Kind regards, > One of the fundamental problems with Java is that you double click on > an executable jar... and nothing happens. Or perhaps the program does [quoted text clipped - 39 lines] > > -Ramon Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.