Speaking of runtime options
Sun Jan 27 17:17:00 GMT 2002
Tom Tromey <email@example.com> writes:
> >>>>> "Nic" == Nic Ferrier <firstname.lastname@example.org> writes:
> Nic> Would a new gij (or a new option handler for the gcj tool) be
> Nic> useful?
> Rewriting the option parsing in gij would be good. Ideally it would
> be Sun-compatible but also comply with the GNU coding standards (i.e.,
> --help and --version already work correctly).
> In what ways are we not compatible?
The heap options have the wrong symbols (in Sun's tools they are Xmx
Other options are are missing (probably because we don't do them).
The cmd line differences between gcj and javac are to many to list.
> One thing we had planned but never implemented was to push some of the
> actual parsing code into the invocation API, as required by the JNI
> spec. It would be nice to do that; have gij parse the options and
> then pass them on to the invocation API somehow. (Whether this is
> fully feasible I don't know.)
Hmmm... How then would the max and initial heap get set? I would have
thought that such options must be present before the VM is
created... but perhaps they could be passed to _Jv_RunMain ?
Is _Jv_RunMain part of the defined invocation API? or is the
invocation API just the JvCreateJavaVM stuff that Per checked in?
If the latter I think gij should use that rather than RunMain.
More information about the Java