Databases
StackOverflow2013
Postsdbo
PODoes Java directory/package hierarchy enforcement allow for jar files to be platform independent?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PODoes Java directory/package hierarchy enforcement allow for jar files to be platform independent?
    primarykey
    data
    text
    <p>I'm sure that I'm misinterpreting something in the Java Language Specification but I can't figure out what. My question is this: On many systems, java forces the directory structure to parallel package names i.e. if the package name is foo.bar then the package files should reside in the folder foo/bar. However, this isn't part of the Java Language Specification and is considered optional. So, what if you had an implementation of Java on one platform that enforced these rules and another implementation that didn't? Would the implementation that required the file hierarchy be able to find the files in the unstructured package used by the other implementation? Does Java always search for class files in all class paths recursively? If so, then why require the package names to mimic the directory structure to begin with?</p> <p>EDIT: For example, suppose that we have two java files one.java and two.java. At the top of these files we prepend "package foo.bar;" thus labeling these files for the package foo.bar. Now, MOST Java implementations will make us put these files into a file hierarchy so that we have /foo/bar/one.java and /foo/bar/two.java. However, according to the JLS this is not required. Now, suppose that we have a Java implementation which does not force us to put them in a hierarchy. That is, we have a .jar file and it has contents one.java and two.java in the top level directory. Now, if we load that .jar file into a system which relies on file hierarchy to locate class files, will it be able to find those class files?</p> <p>EDIT: So, after a little bit of experimentation, I found out that if you set up packages without the appropriate directory hierarchy by jar cvf foo.jar one.class two.class and you try to import them as foo.bar.two and foo.bar.one it just doesn't work even if the packages are specified - you get a NoClassDefFoundError. This is a pretty interesting result to me considering <a href="http://docs.oracle.com/javase/tutorial/java/package/managingfiles.html" rel="nofollow">http://docs.oracle.com/javase/tutorial/java/package/managingfiles.html</a> says, "Many implementations of the Java platform rely on hierarchical file systems to manage source and class files, although The Java Language Specification does not require this."</p> <p>In short, this means that if you are working on an implementation of Java that has decided to use the hierarchical directory structure to manage packages(which is nearly all of them) then the generated jar files may not be compatible with other systems which did not implement the same way. It seems like the Java community has gotten around this by convention, but I'd be interested to hear more if anything has any additional information.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USdoliver
    1. USdoliver
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. CO1- Package names provide name space context, allowing you to have two classes with the same but which reside within separate packages. 2- Java converts a package name into a search when it looks up classes. So if you had a class named `Wally` and it was declared to reside in `foo.bar`, Java would be looking for `foo/bar/Wally.class` by prefixing it's known classpath elements to it, otherwise it wouldn't really know what it was looking for or be sure that it found the right thing :P
      singulars
      1. PODoes Java directory/package hierarchy enforcement allow for jar files to be platform independent?
      1. USMadProgrammer
    2. COWell, here's what's confusing: "Many implementations of the Java platform rely on hierarchical file systems to manage source and class files, although The Java Language Specification does not require this." from http://docs.oracle.com/javase/tutorial/java/package/managingfiles.html. That implies that implementations of java that don't rely on the filesystem hierarchy have some other way to identify where a .class file is. But then a jar file packaged using that system wouldn't be compatible with one that did use the filesystem hierarchy setup because java wouldn't know where to look.
      singulars
      1. PODoes Java directory/package hierarchy enforcement allow for jar files to be platform independent?
      1. USdoliver
    3. COOkay, but even so, MOST implementations of Java rely on a filesystem hierarchy to locate .class files, but it's not required. So, if you had an implementation of Java which did not rely on the filesystem then a foreign Java implementation which did rely on the file system would have no way of locating .class files.
      singulars
      1. PODoes Java directory/package hierarchy enforcement allow for jar files to be platform independent?
      1. USdoliver
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload