Can runtime arguments be included in the manifest?

[Andrew Thompson]

Can runtime arguments be included in the manifest (and be
handed to the main() as a String[])?

I was playing with stand alone Jar's (not applets or webstart)
the other day and could well have used the ability to pass arguments
to the main class. Trawling through the Jar file manifest
specification,
with its conspicuous lack of mention of runtime arguments, makes
me suspect it is not commonly (if ever) done - is that right?

If it can be done, how? I added attributes in the Ant (Manifest) task
as
'arg', 'args', 'argument' and 'arguments' without getting any
arguments
handed to the main class.

 

[Owen Jacobson]

Can runtime arguments be included in the manifest (and be
handed to the main() as a String[])?

I was playing with stand alone Jar's (not applets or webstart)
the other day and could well have used the ability to pass arguments
to the main class.  Trawling through the Jar file manifest
specification,
with its conspicuous lack of mention of runtime arguments, makes
me suspect it is not commonly (if ever) done - is that right?

If it can be done, how?  I added attributes in the Ant (Manifest) task
as
'arg', 'args', 'argument' and 'arguments' without getting any
arguments
handed to the main class.

You're right: they can't. For baked-in configuration, you probably
want a Properties file stored inside the JAR, or to use the
Preferences API with some sensible defaults.

-o

 

[Martin Gregorie]

If it can be done, how?

Either by reading a custom config file or a property file.

Once you realise that the dotted name convention is just decoration a
Java property file is identical with one of the commonest *nix
configuration formats:

- lines or part lines starting with '#' are comments
- 'name = value' defines a configuration parameter.


Best yet, you can still read command line arguments from the

java -jar jarfile mainclass args

command.

 

[Wojtek]

Andrew Thompson wrote :

Can runtime arguments be included in the manifest (and be
handed to the main() as a String[])?

I was playing with stand alone Jar's (not applets or webstart)
the other day and could well have used the ability to pass arguments
to the main class. Trawling through the Jar file manifest
specification,
with its conspicuous lack of mention of runtime arguments, makes
me suspect it is not commonly (if ever) done - is that right?

If it can be done, how? I added attributes in the Ant (Manifest) task
as
'arg', 'args', 'argument' and 'arguments' without getting any
arguments
handed to the main class.

Since the manifest is added when you create the jar, would you not know
what the arguments are?

So just add them before creating the jar.

If you are using versioning with a tool like Ant, then break out the
arguments into separate files and read from that.

 

[Arne Vajhøj]

Can runtime arguments be included in the manifest (and be
handed to the main() as a String[])?

I was playing with stand alone Jar's (not applets or webstart)
the other day and could well have used the ability to pass arguments
to the main class. Trawling through the Jar file manifest
specification,
with its conspicuous lack of mention of runtime arguments, makes
me suspect it is not commonly (if ever) done - is that right?

If it can be done, how? I added attributes in the Ant (Manifest) task
as
'arg', 'args', 'argument' and 'arguments' without getting any
arguments
handed to the main class.

It can not be done.

But you could:
- create another main class with no args
- let manifest Main-Class point to that
- let that call the original main

It gives the same result even though the args are in a .class
file instead of the manifest.

Arne

 

[Daniel Pitts]

Can runtime arguments be included in the manifest (and be
handed to the main() as a String[])?

I was playing with stand alone Jar's (not applets or webstart)
the other day and could well have used the ability to pass arguments
to the main class. Trawling through the Jar file manifest
specification,
with its conspicuous lack of mention of runtime arguments, makes
me suspect it is not commonly (if ever) done - is that right?

If it can be done, how? I added attributes in the Ant (Manifest) task
as
'arg', 'args', 'argument' and 'arguments' without getting any
arguments
handed to the main class.

java -jar myjar My Arguments To "the main class"

Why would you put that in the manifest? If you really needed that
functionality, put a different main class that delegates to the original
main method, passing in the arguments you desire. Otherwise, just pass
them on the command line.

 

[Andrew Thompson]

On Nov 19, 2:56 am, Daniel Pitts

java -jar myjar My Arguments To "the main class"

Why would you put that in the manifest?

So when the user double clicks the Jar, it gets the
arguments that were intended.

I considered making launch files, but you lose x-plat.

I'll go with the alternate main or properties file.

The thing that really tripped me up is that some
JavaHelp launches have an 'arguments' defined in the
manifest - it must be getting access to the value
as a property.

Thanks all.

 

[Owen Jacobson]

...



So when the user double clicks the Jar, it gets the
arguments that were intended.

I considered making launch files, but you lose x-plat.

I'll go with the alternate main or properties file.

The thing that really tripped me up is that some
JavaHelp launches have an 'arguments' defined in the
manifest - it must be getting access to the value
as a property.

Thanks all.

Manifests can be accessed at runtime:

------
import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
import java.util.Enumeration;
import java.util.jar.Attributes;
import java.util.jar.Manifest;

public class ManifestArgumentsUser {
public static void main(String[] args) throws IOException {
ClassLoader loader = ManifestArgumentsUser.class.getClassLoader();

for (Enumeration<URL> manifests = loader
.getResources("META-INF/MANIFEST.MF"); manifests
.hasMoreElements() {
URL manifestURL = manifests.nextElement();
InputStream in = manifestURL.openStream();
try {
Manifest manifest = new Manifest(in);

Attributes mainAttributes = manifest.getMainAttributes();
String arguments = mainAttributes.getValue("Arguments");
if (arguments != null)
System.out.println("Found arguments: " + arguments);
} finally {
in.close();
}
}
}
}
------

It'd be fairly easy to write something to use either the first
occurrence of an attribute or to merge all occurrences of an attribute
in some order. In practice getResources will return the manifests in
the order they appear on the classpath, but I'm not sure if that's
guaranteed.

-o

 

[Andrew Thompson]

Manifests can be accessed at runtime:

Interesting approach..

...In practice getResources will return the manifests in
the order they appear on the classpath, but I'm not sure if that's
guaranteed.

Do you mean manifests in multiple Jar's?

Being in full control of the builds, I *could*
ensure the classpath is set up so the 'args' manifest
is in the first listed jar. OTOH I have been bitten
in the ass more than once by relying on behavior
that Sun did not guarantee.

The properties file sounds the 'most generic and
robust' option.

 

[Andrew Thompson]

..In practice getResources will return the manifests in
the order they appear on the classpath, but I'm not sure if that's
guaranteed.

Was just musing on hard coding a Properties file
name in the main, and it occurred that you might
just as easily hard code the name of the main Jar,
and check that against the paths to the manifest
files that are found.

(I am still leaning toward using the Properties
file.)

 

[Martin Gregorie]

The properties file sounds the 'most generic and robust' option.

Agreed. Don't forget that its trivial to extract/modify/replace the
properties file after the jar has been installed on the target system, so
if some host-specific customisation and/or configuration is needed this
is a good way to do it.