Re: JAVA_HOME and ant
Hallo Mark,
* 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<--
jan@snoopy:/$ 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<--
>> ant is IMO one of the important packages,
>> which should be made working out of the box.
>Have you looked at how the Red Hat people have done it in Rhug or Naoke?
>http://sources.redhat.com/rhug/
>http://people.redhat.com/gbenson/naoko/
I have, but I haven't had a look at the internals.
>> * 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.
>> * Almost all other tasks (cvs, zipper, etc) rely on the fact that the
>> binary is in the path.
>Which binary?
cvs for example. zipper are actually implemented by normal java classes
(bzip, jar, tip) or by ant classes (tar).
>> * 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?
>> * 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.
>> * javadoc relys on the fact that there is a 'bin/javadoc' in java.home
>> or in java.home/../. -> big problem, if that binary doesn't exist.
>gjdoc (which is packaged for Debian both as a traditional byte code
>distribution as a normal application gjdoc-native) should be command
>line compatible with javadoc.
So any 'ant environment' should be able to depend on gjdoc and put a
symlink to java.home/bin/javadoc
>> 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.
>Why can't we patch ant to learn it about other javadoc like programs and
>which options can be used with it?
Because that class is in a such a bad shape (from my point of view),
that patching it to work with alternatives in /usr/bin/javadoc is a
the same as a complete rewrite. Have a look at that class, especially
how the comandline is constructed. That class would score high points
in almost every code metrics... :(
>> * 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.
>Still this seems to be the solution to make Ant really work with other
>free software solutions. It will be much work though and needs
>cooperation with upstream to really work.
Nevertheless, this should be done upstream and not as a debian patch.
>> Can anyone test, what kaffe 1.1.1 sets as java.home?
>For gcj. All system properties, their defaults and what they are used
>for are described in the manual:
>http://gcc.gnu.org/onlinedocs/gcj/System-properties.html
|java.home
|The directory where gcj was installed. Taken from the --prefix option
|given to configure.
Looks ok. If not, patching it shouldn't be a problem...
Thanks for this info!
I really have to upgrade to unstable...
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: