Class-Path entry for a jar manifest file

Discussion in 'Java' started by hiwa, Jan 13, 2004.

  1. hiwa

    hiwa Guest

    To simplify the presentation of the problem, suppose we have the following
    directory structure:

    current directory ... TestApp.class file
    SupportClass subir ... ReadRes.class file
    Resources subdir ... Message.txt file

    Here are the code:

    --TestApp.java--
    import java.io.*;

    public class TestApp{
    public static void main(String[] args) throws IOException{
    ReadRes rs = new ReadRes();
    System.out.println(rs.getStr());
    }
    }

    --ReadRes.java--
    import java.io.*;

    public class ReadRes{
    public String getStr() throws IOException{
    InputStream is = TestApp.class.getResourceAsStream
    ("/Resources/Message.txt");
    BufferedReader br = new BufferedReader(new InputStreamReader(is));
    return(br.readLine());
    }
    }

    --Message.txt--
    Hello World!

    This application runs with an ordinary command line as follows:
    (use ; instead of : on Windows)

    java -cp .:SupportClass TestApp

    Now we have made a jar file with the following command:

    jar mvf manifest TestApp.class SupportClass Resources

    --manifest--
    Manifest-Version: 1.0
    Main-Class: TestApp
    Class-Path: ?????

    Then, the problem is: what should be the correct Class-Path entry in our
    manifest file?

    If you kindly test these jar-archived files, please beware that there
    shoud be no original class/resource files around your testing directories.
    And, note that there is no package issue nor multiple jar files issue
    involved. Here we only see a plain old directory structure.

    Thanks in advance.
    hiwa, Jan 13, 2004
    #1
    1. Advertising

  2. hiwa wrote:

    > To simplify the presentation of the problem, suppose we have the following
    > directory structure:
    >
    > current directory ... TestApp.class file
    > SupportClass subir ... ReadRes.class file
    > Resources subdir ... Message.txt file
    >
    > Here are the code:
    >
    > --TestApp.java--
    > import java.io.*;
    >
    > public class TestApp{
    > public static void main(String[] args) throws IOException{
    > ReadRes rs = new ReadRes();
    > System.out.println(rs.getStr());
    > }
    > }
    >
    > --ReadRes.java--
    > import java.io.*;
    >
    > public class ReadRes{
    > public String getStr() throws IOException{
    > InputStream is = TestApp.class.getResourceAsStream
    > ("/Resources/Message.txt");
    > BufferedReader br = new BufferedReader(new InputStreamReader(is));
    > return(br.readLine());
    > }
    > }


    Classes that belong to a default package instead of an explicit one
    suffer from several limitations, so do yourself a favor and learn to use
    packages. Then when you build a jar, lay out the classes inside it in a
    directory structure corresponding to the package name structure (as it
    is also appropriate to do on the filesystem). Do not seperate classes
    by function, except insomuchas that seperation may already be reflected
    in the assigned packages.

    The class-path header in a manifest file is mainly intended for use when
    you package other jars inside your jar; in that case you specify a list
    of jar names relative to the root of the containing jar file. The
    effect is that classes loaded from your jar will have those additional
    jars in their class path.

    You might want to look at the Jar trail of the Java Tutorial.


    John Bollinger
    John C. Bollinger, Jan 13, 2004
    #2
    1. Advertising

  3. hiwa

    hiwa Guest

    "John C. Bollinger" <> wrote in message news:<bu0ss8$quf$>...
    > hiwa wrote:
    >
    > > To simplify the presentation of the problem, suppose we have the following
    > > directory structure:
    > >
    > > current directory ... TestApp.class file
    > > SupportClass subir ... ReadRes.class file
    > > Resources subdir ... Message.txt file
    > >
    > > Here are the code:
    > >
    > > --TestApp.java--
    > > import java.io.*;
    > >
    > > public class TestApp{
    > > public static void main(String[] args) throws IOException{
    > > ReadRes rs = new ReadRes();
    > > System.out.println(rs.getStr());
    > > }
    > > }
    > >
    > > --ReadRes.java--
    > > import java.io.*;
    > >
    > > public class ReadRes{
    > > public String getStr() throws IOException{
    > > InputStream is = TestApp.class.getResourceAsStream
    > > ("/Resources/Message.txt");
    > > BufferedReader br = new BufferedReader(new InputStreamReader(is));
    > > return(br.readLine());
    > > }
    > > }

    >
    > Classes that belong to a default package instead of an explicit one
    > suffer from several limitations, so do yourself a favor and learn to use
    > packages. Then when you build a jar, lay out the classes inside it in a
    > directory structure corresponding to the package name structure (as it
    > is also appropriate to do on the filesystem). Do not seperate classes
    > by function, except insomuchas that seperation may already be reflected
    > in the assigned packages.
    >
    > The class-path header in a manifest file is mainly intended for use when
    > you package other jars inside your jar; in that case you specify a list
    > of jar names relative to the root of the containing jar file. The
    > effect is that classes loaded from your jar will have those additional
    > jars in their class path.
    >
    > You might want to look at the Jar trail of the Java Tutorial.
    >
    >
    > John Bollinger
    >


    Thanks John for your typical Java adult reply. But here we
    need a solution which doesn't use Java package framework nor
    a set of different jar files. And I firmly believe there would
    be none persuasive rationale for the absense of a viable
    Class-Path entry syntax for a plain old directory structure
    which is jar-archived.
    hiwa, Jan 14, 2004
    #3
  4. hiwa wrote:

    > "John C. Bollinger" <> wrote in message news:<bu0ss8$quf$>...
    >
    >>hiwa wrote:
    >>
    >>
    >>>To simplify the presentation of the problem, suppose we have the following
    >>>directory structure:
    >>>
    >>>current directory ... TestApp.class file
    >>> SupportClass subir ... ReadRes.class file
    >>> Resources subdir ... Message.txt file
    >>>
    >>>Here are the code:
    >>>
    >>>--TestApp.java--
    >>>import java.io.*;
    >>>
    >>>public class TestApp{
    >>> public static void main(String[] args) throws IOException{
    >>> ReadRes rs = new ReadRes();
    >>> System.out.println(rs.getStr());
    >>> }
    >>>}
    >>>
    >>>--ReadRes.java--
    >>>import java.io.*;
    >>>
    >>>public class ReadRes{
    >>> public String getStr() throws IOException{
    >>> InputStream is = TestApp.class.getResourceAsStream
    >>> ("/Resources/Message.txt");
    >>> BufferedReader br = new BufferedReader(new InputStreamReader(is));
    >>> return(br.readLine());
    >>> }
    >>>}

    >>
    >>Classes that belong to a default package instead of an explicit one
    >>suffer from several limitations, so do yourself a favor and learn to use
    >>packages. Then when you build a jar, lay out the classes inside it in a
    >>directory structure corresponding to the package name structure (as it
    >>is also appropriate to do on the filesystem). Do not seperate classes
    >>by function, except insomuchas that seperation may already be reflected
    >>in the assigned packages.
    >>
    >>The class-path header in a manifest file is mainly intended for use when
    >>you package other jars inside your jar; in that case you specify a list
    >>of jar names relative to the root of the containing jar file. The
    >>effect is that classes loaded from your jar will have those additional
    >>jars in their class path.
    >>
    >>You might want to look at the Jar trail of the Java Tutorial.
    >>
    >>
    >>John Bollinger
    >>

    >
    >
    > Thanks John for your typical Java adult reply. But here we
    > need a solution which doesn't use Java package framework nor
    > a set of different jar files. And I firmly believe there would
    > be none persuasive rationale for the absense of a viable
    > Class-Path entry syntax for a plain old directory structure
    > which is jar-archived.


    If you are not satisfied with the way that the URLClassLoader loads
    classes from Jar files then you are free to write your own classloader
    that works however you want. Neither I nor you can force URLClassLoader
    to do what it does not do, however, at least not without violating the
    Java license under which we use the Java SDK.

    I am not in a position to explain Sun's design and implementation
    choices, but I submit that I have never personally found the limitations
    of URLClassLoader to be particularly chafing. I am, on the other hand,
    a bit curious about why you are unable to use packages. Even if you
    have hundreds of source files it shouldn't be too hard to write a script
    to put appropriate package and import statements into all of them, and
    to move them into a correctly structured directory hierarchy if necessary.

    The other alternative is to forget about the internal jar layout you
    described and just flatten it out. (I.e. instead of adopting a package
    structure to match the jar layout you want, modify the jar layout to
    match the package structure you insist on keeping.) I think that would
    work, at least. I'm not certain what the value of any particular
    internal jar's internal layout is if that layout is not required /
    supported by the tools you are using.

    If none of those suggestions are satisfactory then you probably need to
    give the group a better idea of your requirements in order to get much help.


    John Bollinger
    John C. Bollinger, Jan 15, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Karsten Wutzke

    JAR files and manifest: Class-Path

    Karsten Wutzke, Jan 6, 2004, in forum: Java
    Replies:
    6
    Views:
    78,175
  2. cyril
    Replies:
    2
    Views:
    3,831
    cyril
    Aug 25, 2004
  3. Replies:
    10
    Views:
    3,478
  4. Cameron McCormack
    Replies:
    0
    Views:
    359
    Cameron McCormack
    Aug 27, 2007
  5. =?iso-8859-1?B?UulnaXMgROljYW1wcw==?=

    Specify a directory in the Class-Path entry of the Manifest

    =?iso-8859-1?B?UulnaXMgROljYW1wcw==?=, Oct 29, 2007, in forum: Java
    Replies:
    4
    Views:
    1,110
    Almond
    Oct 31, 2007
Loading...

Share This Page