Re: java-compiler useless?
On Fri, Oct 04, 2002 at 02:19:17PM +0100, Mark Howard wrote:
> On Fri, 2002-10-04 at 11:48, Ola Lundqvist wrote:
> > Policy feedback is apriciated. How do you think the text should be
> > instead?
Hi
Thanks for the text.
> 2.2. Java compilers
>
> Java compilers must depend on java-common and the needed runtime
> environment (java1-runtime and/or java2-runtime).
>
> Where possible, java compilers should include a javac wrapper named
> compilername-javac-wrapper (e.g. gcj-javac-wrapper). If this complies to
> the following terms, then the package should provide java-compiler or
> java2-compiler and use the alternatives system for the name 'javac'.
I think we have come to a conclusion saying that java2-compiler
is not necessary.
> Java compilers not satisfying these terms must not provide
> java-compiler.
Sounds good.
> - Generated output is standard java bytecode [as defined by ...??] and
> stored in files of the form MyClass$MyInnerClass.class.
Do anyone know of a good reference?
> - javac --version will print the full name and version of the compiler
Ok.
> - Command line arguments are of the form javac [options] sourcefiles
> - The following options must be implemented. Other options may exist
> also
> -classpath classpath
> classpath is a colon separated list of jar files and directories
> searched for compiled java bytecode.
> -d directory
> sets the destination directory for the class files.
>
>
> Notes:
> - should we use Sun style -classpath or GNU standard (and so gcj style)
> --classpath ?
Should we enfoce both of them?
> - If packages build-depend on java-compiler, --version will be useful to
> see which one is being used. Alternatively, perhaps it would be a good
> idea to say that this information should be printed whenever javac is
> run - this would be especially useful for users who aren't familiar with
> the alternatives system.
Well the javac program should be quiet I think.
> - Not sure if wrapper naming is needed, but it might make it clearer to
> have such a convention (it would differentiate between upstream compiler
> and the wrapper)
I do not think it is necessary. In some cases you might not need a
wrapper.
> - Sun's javac creates directories below the -d directory following the
> class name e.g. -d work com.debian.test -> work/com/debian/test.class.
> This would be slightly more difficult to implement in a wrapper script,
> so I think it is best to say this shouldn't happen.
Well then the upstream have to change, right?
> - should @files also be included? (allows the user to give the name of a
> file containing source file names rather than listing the source files
> directly)
I do not know (never used it). What do other people think about this?
> Also, something similar should be done for section 2.1:
> 2.1. Virtual machines
>
> Java virtual machines must depend on java-common.
>
> If possible, they should provide a 'java' wrapper script named
> jvm-name-java-wrapper [again, not sure if necessary] to be used with the
> alternatives system. If the wrapper complies to the following terms then
> the package should provide java-virtual-machine and java1-runtime or
> java2-runtime as appropriate [?is this correct?]
>
> The java wrapper should allow the following calling conventions:
> java [ options ] class [ argument ... ]
> java [ options ] -jar file.jar [ argument ... ]
>
> The following options must be implemented, although others may also
> exist:
> -classpath
> [same as above]
>
> JVM's should have a CLASSPATH predefined which include the needed
> runtime environment.
Yes. Now to the question. Should it override the CLASSPATH
and/or -classpath? I do not think so. It should be written in the
policy.
> If a given source (like the JDK does) brings both a compiler and a
> virtual machine, you may name the compiler package xxxx-dev.
Well you do not have to say such things in policy I think.
Regards,
// Ola
> --
>
> +----------------------------------------------+
> | Mark Howard cam.ac.uk mh344@ |
> | http://www.tildemh.com tildemh.com mh@ |
> +----------------------------------------------+
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Annebergsslingan 37 \
| opal@lysator.liu.se 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: