I am reading packaging java applications with jar tool. I noticed a manifest file is created under META-INF directory. For a simple application, it felt like, it's serves no purpose. I searched on stackoverflow to understand the usages of Manifest file. I came across UsesOfManifestFile. While reading the answer, i got confused on point 2 and 3 which are :-
What are download extensions? I am not able to understand the concept in the answer.
What does it mean to seal the jar? It has given an example below like this
Name: myCompany/MyPackage/ Sealed: true
What is the use of putting such information? Can someone elaborate on these points.
Thanks.
The manifest file is like the guidance instructions for the java program to run the jar. When the manifest is created it will hold crucial information, for example a reference to the main program. When the java program runs your jar it doesn't know where to start, so it look sin the manifest for a line telling it where the class with the main method is so it has a start point for the program. Another use is a classpath line, which will tell the program where to find any 3rd party library's in the jar are, otherwise again, the java program won't find them.
There is a range of data that can be stored in the manifest file, I would recommend checking out the Oracle information on them and seeing if that clears it up a bit more.
EDIT: From the Oracle site regarding your example:
Packages within JAR files can be optionally sealed, which means that all classes defined in that package must be archived in the same JAR file. You might want to seal a package, for example, to ensure version consistency among the classes in your software.
You seal a package in a JAR file by adding the Sealed header in the manifest, which has the general form:
Name: myCompany/myPackage/
Sealed: true
The value myCompany/myPackage/ is the name of the package to seal.
Note that the package name must end with a "/".
What this appears to mean is that any and all classes that you use in your program must be within the same jar file.
EDIT 2 (For comment response)
A manifest may contain the following line:
Main-Class: com.mkyong.awt.AwtExample
When the javaw.exe (I think) runs your runnable jar, it has no idea where to start from, all java programs run via a main method, but if you have say 50 class files in your jar, it has no idea which one has the main method to start from. It will look at the manifest file, reads your above line and thinks right, the main method is in the package com.mkyong.awt and the class is AwtExample, it then finds this class and runs the program from that main method. It's most basic function within the jar is to tell the java program running the jar where to find the stuff it needs to run your jar.
Note: that example manifest entry came from a little tutorial which shows how to create a simple runnable jar.
Good Luck!
Related
In this previous question, I was trying to rework some Matlab code and figure out a package called javaplex to be compatible with Octave; it uses Java, but is tooled for Matlab, hence that issue. Now in an interval of time, I was busy/running simulations, and hadn't gotten around to a final step - actually using the package, with most all of the difficulties worked out. It turns out that another step exists: I need to convert an Octave array to a Java array (although I'm not sure why this issue didn't come up in Matlab).
To do so, I have turned to this script, in which the comments indicate that when using it, it
Assumes the JIDT [Java Information Dynamics Toolkit] jar is already on the java classpath - you will get a java classpath error if this is not the case.
So I go to the JIDT GitHub page and download this package. Now I am not a very avid user of java, so I believe I am failing to see something fairly straightforward: I am not sure where the "JIDT jar" is that is referenced in the above block quote! I can't find such a particular jar file to put in Octave's java classpath. In this tutorial for JIDT, they say you need the "infodynamics.jar" file in the classpath (page 9). I'm not sure what jar file I should be looking for, and where. Any help understanding the nature, name and location of this jar file (within the infodynamics toolkit folder) would be appreciated!
As an inevitable follow-up question, because this will come up upon resolving this issue, I would like to clarify the following procedure is how to add a jar file to the Octave (static) java classpath (following this answer here, I wasn't sure if I was implementing correctly):
I create a file called "javaclasspath.txt" inside of the directory I use in Octave.
I enter the name of files as follows: "./path/to/your-file.jar"
I suppose my main issue here is where do I start the path (all the way back with "C:/..."?), and do I put this "javaclasspath.txt" file in the directory folder I will be using most of the time in Octave?
Edit: I cannot find "infodynamics.jar" as shown here:
The JIDT jar is named infodynamics.jar and it is located in the root of the downloads infodynamics-dist-1.4.zip file.
I am new to java,i have setup eclipse java project.I have a set of classes in jars in a folder.I have also got the java files associated to those classes downloaded (i cant compile those java files,its just to read and debug at runtime).My issue is class files are packaged in a different way than the those what appears in java file.
eg:- ABC.java is structured as platform\src\main\java\com\subplatform\sql\ABC.java
But package declared in java file if i open is
com.subplatform.sql;
I think this is the reason the debug point is not getting honored.In the previous version's of this product
java files used to be structured as
src\com\subplatform\sql\ABC.java
Thus it used to stop at the debug point.
Thanks
Rename all the package information that contains package com.[restOfPackageInfo] to be package java.com.[restOfPackageInfo] and you should be all set. (Also, if there are any import statements, you'll need to add java in front of com there too.)
There's your problem:
Originally the file structure was "src\com\subplatform\sql\ABC.java"
But by creating a folder called java and placing the com folder inside, you're changing the path to be: "src\main\java\com\subplatform\sql\ABC.java"
So, essentially in the ABC file you see package com.subplatform.sql;. This is information that the compiler uses to compile the class. So you're compiler looks for a ABC.java in src with path com.subplatform.sql but there is no such folder.
Also, read up on packaging.
It sounds like your source attachment path is wrong and should point to platform\src\main\java\ instead of the project itself.
A debug point not being honored can mean two different things.
1) The debugger isn't stopping on line breakpoints. If the compiled class files don't have line and debug information, the JVM doesn't know when it's executing those lines and will not stop there. You should still be able to stop at method entries and when exceptions are thrown. Either way, your are always required to launch your application using Debug instead of Run.
2) The debugger is stopping, but the source is not found. For a JAR file, you should have the properties of the JAR's entry on the Java Build Path point to a location where the source files exactly match the layout of the jar so that com/novice/to/sql/MyClass.class has a com/novice/to/sql/MyClass.java relative to where ever the source attachment points. If the top level contents of the JAR file contains entries like "com", "org", and "net", that's what should be in the top level of the source directory or archive you're pointing to.
I understand that there are many similar questions and answers, but none of the answers fit what I am trying to do. I have a file called gui.java and I am trying to turn it into a jar file, LifeGame.jar I keep the .java and the .class in a folder, and when I try to archive it, it works, but when I try to run the file, it gives me Could not find or load main class gui. I do give a manifest called "META-INF:MANIFEST.MF" and the folder is stored on my desktop.The manifest looks like:
Main-Class: gui
I would like some advice on what to do and how to fix this problem. (As I have already said, I understand this is a clone of many other questions, but the examples I've seen don't work for me in my situation)
EDIT:
Some details on my scenario:
I have multiple classes in gui.java but only one of them is public, the rest aren't private of public. It is on my desktop and when I try java gui it gives the same error as when I try archiving it into a Jar.
Name of your main class should be gui. check your .class file which is created to be gui.class or any other. It doesn't matter the name of .java file but the name of .class file.
My code has gotten quite large and so I've decided to build a runnable JAR to see how it's done. I probably should've tried sooner because I'm getting 2 different errors related to the project structure, first is the "no main manifest attribute error" when trying to run the JAR from command prompt. Double-clicking the JAR does nothing (Win7). The second issue is related to the FXMLLoader explained lower down.
I followed the steps here to build the JAR, which involved moving all Maven files into the JAR directory. The compiled JAR gave me the manifest error, so I followed this which adds a Maven plugin in my pom.xml file. The error might be caused by a wrong naming convention with the line <mainClass>com.primary.Drag</mainClass> where primary is the package and Drag is my Drag.java file (class) which has the main method.
Inititally I was using the default package but read that this is not recommended for larger projects, so I put all my files into "primary". Here is my current hierarchy as shown in IntelliJ:
The problem is that ever since I created the "primary" package, I can no longer even compile the program via IntelliJ, let alone build a runnable JAR. This is due by the second error I mentioned, which is java.lang.IllegalStateException: Location is not set. on this line within primary/Drag.java:
FXMLLoader loader = new FXMLLoader(getClass().getClassLoader().getResource("firstlaunch.fxml")); It used to work with the default package, but not anymore.
I tried replacing firstlaunch.fxml with /primary/firstlaunch.fxml and /resources/firstlaunch.fxml (with and without moving resources into primary package) but no luck.
3 Related Questions:
Is my project structure incorrect?
How do I reference the fxml file from the primary package?
Is this what I should write in Maven's mainClass tags? <mainClass>com.primary.Drag</mainClass>
Is my project structure incorrect?
Answer:
Your package name should be like com.primary.******
How do I reference the fxml file from theprimary package?
Answer:
Always make sure that you are trying to load firstlaunch .xml from the class which is located in same package where that xml is kept. Means class which you wrote the loading code and xml file should be in same package
Is this what I should write in Maven's mainClass tags?com.primary.Drag
Answer:
If you package name corrected to com.primary , your main class Drag will correctly added by maven
I am using one third party jar in my code. In the jar file , in one of the classes, when I opened the class using de-compiler, the code below is written:
java.net.URL fileURL = ClassLoader.getSystemResource("SOAPConfig.xml");
Now I am using this in my webapplication, where should I place this SOAPConfig.xml so that it will find the fileURL.
Note: I have tried putting this XML in WEB-INF/classes folder. But it is not working. Your help will be appreciated.
In Addition: In the explaination you have given, It is telling me not to use this code snippet inside the third party jar in this way...What is the exact usage of this statement
ClassLoader.getSystemResource will load the resource from the system classloader, which uses the classpath of the application as started from the command line. Any classloaders created by the application at runtime (i.e. the one that looks in WEB-INF/classes) are not on the system classpath.
You need to
Look through the script that starts your server, find out which directories are on the classpath there, and put your SOAPConfig.xml in one of those. If necessary, change the classpath in the script to look in a separate directory that's just used for your config file.
Track down the person who used ClassLoader.getSystemResource in the library, kick them squarely in the nuts, and tell them never to do that again.