Command line options in Jar files?
[162 byte] By [dnoyeB] at [2007-9-26 3:07:37] 
Can I set a command line option in the manifest of my jar file so that when it is double clicked it will invoke the JVM with my command line option?
Don't think so.But you could specify defaults in your program for the command line arguments. If you don't get anything on the command line then use the default.
jschell at 2007-6-29 11:11:32 >
you can try creating a short cut that point to java.exe (or javaw.exe which does not display a console, if your program is a pure GUI thing). And you can specify the jar file (or class) and command line arguments in the short cut. It works beautiful in my NT box. An example could be:
create a short cut to java.exe (or javax.exe)
click right mouse button to pop the attribute box.
in the 'Shortcut' tab-pane, give the full command line in 'Target' text field, say:
c:\jdk1.3\bin\java -jar c:\your_dir\your_jar_file.jar arg1 arg2
also, you could specify classpath there. Anyway, in the target field, you could give exactlly the same line as command line.
andy.g at 2007-6-29 11:11:32 >
> Don't think so.> > But you could specify defaults in your program for the> command line arguments. If you don't get anything on> the command line then use the default.Trying to pass to the JVM, not my code.
dnoyeB at 2007-6-29 11:11:32 >
> you can try creating a short cut that point to
> java.exe (or javaw.exe which does not display a
Yes, got all kinds of shortcuts and batch files now.But what if the user clicks on the jar file instead? I wish i could just put it in the manifest.
Actually I wish sun would just fix the dang option to work as it should and not need to be on the command line...
-Dsun.net.inetaddr.ttl=10
> console, if your program is a pure GUI thing). And you
> can specify the jar file (or class) and command line
> arguments in the short cut. It works beautiful in my
> NT box. An example could be:
> create a short cut to java.exe (or javax.exe)
> click right mouse button to pop the attribute box.
> in the 'Shortcut' tab-pane, give the full command line
> in 'Target' text field, say:
> c:\jdk1.3\bin\java -jar c:\your_dir\your_jar_file.jar
> arg1 arg2
> also, you could specify classpath there. Anyway, in
> the target field, you could give exactlly the same
> line as command line.
dnoyeB at 2007-6-29 11:11:32 >
>Trying to pass to the JVM, not my code.
I see.
>Actually I wish sun would just fix the dang option to work
>as it should and not need to be on the command line...
And that won't happen.
Your presumption is that the manifest could somehow do the command line options. But by the time the manifest and jar file is read, the JVM is already running and fully functional. Most of the functionality that you see in the jvm is actually implemented by other java classes. So the JVM has to be running before it can do anything.
With sun jdk 1.3 a hello world program loads 180+ classes. This is not pre-loading but rather load on demand, it needs all of those classes to load, resolve and run the hello world program.
jschell at 2007-6-29 11:11:32 >
OK, I see. JVM won't read manifest file to get params. If you really want to do that, the only work around that I could find is to write a small agent program (C/C++ or Java or whatever that can read file and start a new process), associate the .jar file type to it. In this small agent, you read the manifest file, then start the JVM with the params.
andy.g at 2007-6-29 11:11:32 >
> >Trying to pass to the JVM, not my code.
>
> I see.
>
> >Actually I wish sun would just fix the dang option to
> work
> >as it should and not need to be on the command
> line...
>
> And that won't happen.
>
> Your presumption is that the manifest could somehow do
> the command line options. But by the time the
> manifest and jar file is read, the JVM is already
> running and fully functional. Most of the
> functionality that you see in the jvm is actually
> implemented by other java classes. So the JVM has to
> be running before it can do anything.
>
> With sun jdk 1.3 a hello world program loads 180+
> classes. This is not pre-loading but rather load on
> demand, it needs all of those classes to load, resolve
> and run the hello world program.
>
>
Actually I am aware of the classes which implement this functionality. It would be VERY easy for sun to empty the connection cache, they just choose to not let us do it for whatever bonehead reason. ANYONE who uses an internet inabled java application/applet will have this issue. Is java supposedly internet friendly?
Just try it. unplug your internet, use a java application to try and connect to some URL (telnet, ftp, whatever). Plugin your internet connection and see that you will not be able to connect untill you restart your app.
Crazy. This should be implemented. Its got 2 be a bug. they dont even tell you its command line only...
dnoyeB at 2007-6-29 11:11:32 >
>Actually I am aware of the classes which implement this functionality.
>It would be VERY easy for sun to empty the connection cache...
Huh? I was thinking more along the lines of things like the java heap and the allocation stack size per thread.
Especially with the thread stack size, I don't see how you could reset that without reworking a lot of stuff (and what happens to security?)
jschell at 2007-6-29 11:11:32 >
> >Actually I am aware of the classes which implement
> this functionality.
> >It would be VERY easy for sun to empty the connection
> cache...
>
> Huh? I was thinking more along the lines of things
> like the java heap and the allocation stack size per
> thread.
>
> Especially with the thread stack size, I don't see how
> you could reset that without reworking a lot of stuff
> (and what happens to security?)
I think you missed my point totally. I wish sun would fix the -Dsun.net.inetaddr.ttl=10 property, not add command line functionality to the manifest.
Thats what I was saying. so if they fixed that property, I wouldnt be asking for command line functionality in jar files because I could set this option from within my program. But I cant.
dnoyeB at 2007-6-29 11:11:32 >
>I think you missed my point totally.
Actually, I was responding to your first thread which didn't specifically specify a particular option.
However, it still applies. That is still a command line option. And presumably it changes how the compiler starts. If that is the case then the only legitimate way to do that would be to have the jvm do a restart once it found the parameter in the manifest. As I pointed out by the time it gets to your manifest file the jvm is up and running, so a restart is the only way to guaranteee that all affect modules are correctly started.
However, if this does not affect how the jvm starts then the best way would be to add an api interface which allows you to change the value after the jvm starts. If that is the case then you should submit a RFE and/or a JSR to implement that.
jschell at 2007-6-29 11:11:32 >
> >I think you missed my point totally.
>
> Actually, I was responding to your first thread which
> didn't specifically specify a particular option.
>
> However, it still applies. That is still a command
> line option. And presumably it changes how the
> compiler starts. If that is the case then the only
> legitimate way to do that would be to have the jvm do
> a restart once it found the parameter in the manifest.
> As I pointed out by the time it gets to your manifest
> file the jvm is up and running, so a restart is the
> only way to guaranteee that all affect modules are
> correctly started.
>
> However, if this does not affect how the jvm starts
> then the best way would be to add an api interface
> which allows you to change the value after the jvm
> starts. If that is the case then you should submit a
> RFE and/or a JSR to implement that.
No. trace the code and you will eventually find where this option could be settable, but is not allowed. In any event.
1. they should specify it as command line only.
2. They should change it from command line only.
I think this is in 1.4 so no matter. But I was still throwing the question out there about setting command line options in jar file invocations because I wanted to know what people though about that.
dnoyeB at 2007-6-29 11:11:32 >
> >I think you missed my point totally.> > Actually, I was responding to your first thread which> didn't specifically specify a particular option.By your second responce I had already specified the option I was interested in.
dnoyeB at 2007-6-29 11:11:32 >
> I think you missed my point totally. I wish sun would
> fix the -Dsun.net.inetaddr.ttl=10 property, not add
> command line functionality to the manifest.
>
> Thats what I was saying. so if they fixed that
> property, I wouldnt be asking for command line
> functionality in jar files because I could set this
> option from within my program. But I cant.
don't you think you could set this property via System.setProperties() method? -Dxxx=yy things could be got via System.getProperties(), so you can set any system properties. use System.setProperties() have the same effect as -Dxxx=yy
or i misunderstand something?
andy.g at 2007-6-29 11:11:32 >
>so you can set any system properties. You can set them. But it is likely to have no effect. By the time you can set them the jvm has already used them so you setting them has no effect.
jschell at 2007-6-29 11:11:32 >
well, it's up to when does the JVM load the sun.net.InetAddressCachePolicy class. when loat that class, it use the sun.net.inetaddr.ttl to set the cache policy.
ok, let's assume it is loaded when the JVM's starting up, we still can set the cache policy by the class's static method:
sun.net.InetAddressCachePolicy.setIfNotSet(int i)
as the method name indicated, if you haven't set the attribute via -D, you could set it in your program.
try it to see whether it works. :-)
SUN put some stuff in sun.xxx packages, such as the implementation of socket, input/output stream, awt etc, and those classes and APIs are not part of core Jave API, though the implementation of core JAVA API uses these hidden API, that's why we found we have less control of some functions than SUN's program.
Anyway, it's a work aroud not a perfect solution, as SUN can change the classes/methods in sun.xxx package without any notification, so, any code uses those API may end up with being incompitable with new/old version of java.
andy.g at 2007-7-1 3:20:56 >
having hacked the source code of InetAddressCachePolicy, it seems the method setIfNotSet(int i) does not work, as the initial policy is -1 (wihtoud -D property), and if(i>cachePolicy || i<-1) throw some exception. seems it does not want any change of the policy after static initialization, doesn't make sense, why there is such a method?!
so, the cache policy can only set by using -D, or, if the initialization is not executed at JVM start-up, use System.setProperties() should work.
andy.g at 2007-7-1 3:20:56 >
> having hacked the source code of
> InetAddressCachePolicy, it seems the method
> setIfNotSet(int i) does not work, as the initial
> policy is -1 (wihtoud -D property), and
> if(i>cachePolicy || i<-1) throw some exception. seems
> it does not want any change of the policy after static
> initialization, doesn't make sense, why there is such
> a method?!
>
> so, the cache policy can only set by using -D, or, if
> the initialization is not executed at JVM start-up,
> use System.setProperties() should work.
>
What do you mean? System.setpropertits and security setproperties dont work.
How am I supposed to add this -D?
Security.setProperties("-Dsun.net.inetaddr.ttl",1);
?
You took the words right out of my mouth. Yes I have tested it and traced thru the source too...
dnoyeB at 2007-7-1 3:20:56 >
> having hacked the source code of
> InetAddressCachePolicy, it seems the method
> setIfNotSet(int i) does not work, as the initial
> policy is -1 (wihtoud -D property), and
> if(i>cachePolicy || i<-1) throw some exception. seems
> it does not want any change of the policy after static
> initialization, doesn't make sense, why there is such
> a method?!
>
> so, the cache policy can only set by using -D, or, if
> the initialization is not executed at JVM start-up,
> use System.setProperties() should work.
>
I tried it again. possibly they fixed it in 1.3.1 because it certainly works today!
dnoyeB at 2007-7-1 3:20:56 >
Try this: http://forum.java.sun.com/thread.jsp?forum=22&thread=362499
DougSchake at 2007-7-1 3:20:56 >
Core New Topic
Core Hot Topic
Core
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding