Hi, On Sat, 2003-09-06 at 17:29, Jan Schulz wrote: > * Mark Wielaard wrote: > >gij does come with a normal long-option --classpath. But as the gij help > >output says: "Options can be specified with `-' or `--'." > > --8<---------:- snip -:---------8<---------:- snip -:---------8<-- > [EMAIL PROTECTED]:/$ gij-3.0 --help > Usage: gij [OPTION] ... CLASS [ARGS] ... > to interpret Java bytecodes, or > gij -jar [OPTION] ... JARFILE [ARGS] ... > to execute a jar file > > -DVAR=VAL define property VAR with value VAL > --help print this help, then exit > --ms=NUMBER set initial heap size > --mx=NUMBER set maximum heap size > --version print version number, then exit > --8<---------:- snip -:---------8<---------:- snip -:---------8<--
Try gij-3.3:
$ gij-3.3 --help
Usage: gij [OPTION] ... CLASS [ARGS] ...
to interpret Java bytecodes, or
gij -jar [OPTION] ... JARFILE [ARGS] ...
to execute a jar file
--cp LIST set class path
--classpath LIST set class path
-DVAR=VAL define property VAR with value VAL
--help print this help, then exit
--ms=NUMBER set initial heap size
--mx=NUMBER set maximum heap size
--showversion print version number, then keep going
--version print version number, then exit
Options can be specified with `-' or `--'.
See http://gcc.gnu.org/java/ for information on reporting bugs
> >> * Javac isn't a problem, as it uses Class.forName() for almost
> >> everything or simple assumes, that the binary is in the path. Can be
> >> made working with alternatives, by specifying a classpath wihich
> >> include the build.compiler.
> >Would it be a good idea to write a wrapper class that can be called by
> >the traditional Class.forName() contruct but that just invokes the
> >wanted compiler?
>
> There are already wrapper classes for jikes, kjc and so on. basicly
> the algo is like this:
> if default, then use sun...javac.Main
> if 'shortname', then use wrapperclasses around the compilers
> if 'classanme', then use Class.forName() and call execute (or so).
>
> All compilers I know should be satisfied by that.
OK. I am not a big Ant user. gcj needs a -C option to compile to byte
code though. Or a --main <package.MainClass> and -o <binary.name> option
for compiling to native code.
> >> * Javah relies on a special sun.com...javah.Main class. Doesn't matter..
> >gcj comes with gcjh which should be able to do everything javah does
> >(given the -jni flag).
>
> But as it is now, it won't be useable form ant. Or does gij include
> the sun....javah.Main class?
No. It is a normal program written in C.
In principle gcj doesn't implement undocumented classes.
> >> * some tasks rely on 'bin/java' or 'bin/jarsigner' in java.home
> >> or java.home/../ -> big problem, if that binary doesn't exist
> >I don't know of a free jarsigner compatible program. But as far as I
> >know most (all?) free core library implementations don't implement jar
> >verification at all.
>
> jarsigner is IIRC only usefull for applets.
And other programs that assign protection domains to dynamicly loaded
byte code classes. But I don't know of any free implementations. It
shouldn't be that hard to write though if there is demand.
> >> For the last two problems see the JavaEnvUtils class.
> >A quick look at that class suggests that it makes all kinds of
> >assumptions about what class availability says about versions and the
> >availability of other classes. It should probably be patched to test for
> >more features and make less assumptions of what is/isn't available.
>
> Yes, but to make this policy os do something else is IMO not possible.
> Especially, if we have to consider, that ant should behave 'normaly',
> when used to develop java apps in, for example, eclipse.
How do you define normally?
If Ant can only work correctly with non-free programs or VMs then it
isn't really useful for main is it?
> >> * Patch all VMs, so that java.home points to the right dir, which
> >> includes this commands in the right version (symlinks, Depends:).
> >Why should a VM provide all the applications? I know kaffe tries to do
> >this and to a lesser extend gcj comes with a couple of "standard" java
> >development tools. But most VMs can probably rely other free
> >implementations of these tools.
>
> So from debians POV, it shouldn't be a problem to 'construct' such
> 'ant environments'. Note that not the Virtual maschien should provide
> all this tools but a 'ant environment'. See the 3 attempt of my
> proposal.
OK. It is just that I am not such a big Ant user so I have some
difficulties seeing how this works.
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
