Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Mark,
* Mark Wielaard wrote:
>I am one of the GNU Classpath developers but not a Debian developer.
Thanks for joining anyway :)
>For end-user programs I think it would be a good idea to mention that
>gcj can be used to compile programs written in the java language into
>normal native binaries that are quicker to run and startup. For the end
>user it doesn't matter that it can also be compiled to byte-code and
>interpreted during runtime.
This would mean, that the resulting package will not use 'java' to
start the programm and it would be a normal ELF binary, for which all
teh rules from the debian policy apply.
Also, this is a policy for packaging java apps and libraries. This is
not really intended to be used by users, but by debian devloper. If
they choose to supply their java app as a ELF binary, thats up to them.
But your Q/A would be a topic for the debian java FAQ.
>> 2.1. Java virtual machines and runtime environments
>How is sun compatible defined? What specs should a vm/runtime implement
>to be regarded sun compatible?
Actually I don't really mind, as long as it works. :) This paragraph
should work with three VMs: Sun, IBM and Blackdown. They are similar
enought to work with them based on such a interface.
Re 'spec': java-virtual-maschine-1.4 will need to implement the java
spec version 1.4. As Java evolves, there will be more virtual
maschiens. If java packages need tighter dependencies, more virtual
packages should be proposed and used.
Maybe the java policy should link to a file, which holds the current
state of this virtual packages.
>> Packages should access sun compatible java virtual maschiens via the
>> described "unfree" interfaces below.
>If it is a "unfree" interface should it be mentioned at all in a
>official Debian main policy?
Yes. Debian social contract also says:
5. Programs That Don't Meet Our Free-Software Standards
|We acknowledge that some of our users require the use of programs
|that don't conform to the Debian Free Software Guidelines. [...]
|Thus, although non-free software isn't a part of Debian, we support
|its use, [...]
I'm not happy with 'unfree interface', but thats IMO the clearest name
for this interface.
>> Other virtual maschines should be tested seperatly and, if the VM
>> can be used to run the code, then accesed via their main binary, not
>> via the alternative system.
>So the alternative system is only usable with non-free VMs?
Jain: The alternative system is used to setup the 'unfree interface'.
It is also used to setup the /usr/bin/java binary. Due to the fact
that package, which setup a alternative for /usr/bin/java are too
diffrently, we can't use this binary with package.
This will give packages the chance to supply specific comandlien
arguments for each regular packaged JVM and use the unfree interface.
This should be 'good enough'.
>> 2.1.1. bin/java
>> A alternative for /usr/bin/java and the corresponding manpage should
>> be setup by every package, which provides java2-runtime. This comand
>> should not be used by any debian package.
>What should a package satisfy to be able to provide java2-runtime?
Basicly the same requirements as now: be a java virtual maschine.
Policy never made any requirements, on java2-runtime or java1-runtime.
I droped the java1-runtime, because I think that most packages will
not require a java1-runtime.
>> All java virtual maschines must depend on java-common.
>What does java-common provide?
(this is already a requirement now)
Now: Policy, FAQ, some equivs files, 'classpath example'
After the policy change: "Now" + java-config
This is (AFAIK) used to have a way to affect all java packages by one
package.
>> 2.1.3. JNI library path
>> Some Java classes implement their routines using a "native" language
>> (such as C). This native code is compiled and stored in dynamic
>> libraries (such as JNI modules) that are loaded at runtime. If a
>> virtual machine supports native code, it must include the directory
>> /usr/lib/jni in its search path for these dynamic libraries, even if
>> that has to be setup via a wrapper scripts.
>Are there any other requirements? Should /lib and /usr/lib be searched
>or not for example?
JNI Libs should be placed in /usr/lib/jni (see library section). What
would be the usecase to include more than this directory on this
search path?
>> 2.2. Java Development Tools
[..]
>Ant is used by some packages, but why mandate that ant must be used?
Is now changed to 'If package uses ant, then it must... \n If not, ...'
>Have you looked at how Rhug handles this? It has a more traditional
>auto* setup to make compiling lots of packages (bcel, bouncy castle,
>bsf, jakarta-commons, java-cup, ecj, gnu.regexp, ant, log4j, jasmin,
>junit, jdbc-drivers, rhino, xalan and xerces) with gcj easy. If debian
>adopted the rhug way then all the above packages would instantly go into
>main.
This would mean, that all java packages have to be compield to native,
which is IMO not the best (one argument: all classes, which are loaded
by reflection and not compield to native are used in interpreter
modus -> no speed advantages at all. Also: gcj isn't that far in
debian).
>> 2.2.1. Ant Environment
>I would try to separate the API version (which will bee hard enough to
>define precisely given that most free vms don't explicitly follow the
>API versions as defined by sun) and the version/command-line options
>that the javadoc like program must have.
The problem is, that it should work with ant and ant uses javadoc in
this way:
get JVM version by testing for some classes, which are new in that version
Use bin/javadoc and set options based on the JVM version.
As I said: patching this task in ant isn't an easy sollution, as it
probably needs a complete rewrite.
I think the easiest would be to say that the requirement to supply a
'ant environment' would be to run succesfully a test suite.
Unfortunatelly, there is currently no javadoc testcase in the ant
package :(
>> They also must include a java-config file (see below) which includes
>> the variable declaration for JAVA_HOME, which points to
>> /usr/lib/name, ANT_BUILD_COMPILER with the name or full qualified
>> classname of the java compiler and the JARS entry, with the jars
>> needed to run this java compiler.
>Why a fully qualified classname and jars?
Because there are java compiler developed in java -> the eclipse
compiler can be used with ant.
[..] ANT_BUILD_COMPILER with the short-name or the full qualified
classname of the java compiler [..]
Also, for the default environemt, it needs to include the tools.jar.
>It won't be that hard to
>create wrapper classes that call the binary that the package want to use
>as compiler, but it might be better to allow a package to just speecify
>a compiler command (like jikes-classpath, gcj -C, kjc or ecj).
Thats what I meant. More or less. Ant uses a specal interface to use a
java compiler. jikes is for example used via
org/apache/tools/ant/taskdefs/compilers/Jikes.java
>What does it mean to provide java2-compiler? Are there any special
>input/output files and/or command-line arguments that must be supported?
Its basicly the same as now: it needs a java compiler, but no other
requirements are made. As I have learned during the discussion about
this, it's not possible to 'draw the line'. If a user wants to use
/usr/bin/javac it's up to the user and the user can read teh manpage
for all options. A package should use /usr/bin/jikes (or other) or the
ant environent.
>> Packages which setup a alternative for /usr/bin/javadoc must provide
>> javadoc.
>What does it mean to provide javadoc? Are there any special input/output
>files and/or command-line arguments that must be supported?
Se above. /usr/bin/javadoc shouldn't be used by packages.
>For both these alternatives wouldn't it be better to just recommend just
>one free application for compiling and generating javadoc?
A package may choose, which javac or javadoc commandit may use. This
way, the package has control over the the actual command, which is used.
>> 2.3. Java Browser Plugin
>Aside. Is gcjwebplugin packaged for Debian?
>http://www.nongnu.org/gcjwebplugin/
Not that I know.
>If you want to promote gcj a bit then I suggest that you recommend
>pacakges to also produce lib-some-package-name.so files that can be
>automatically loaded by gij. That speeds up loading a lot since then the
>classses are precompiled.
This is a nice feature, but IMO it should be added in a seperate
proposal after this one, if that is wanted.
[java-config proposal]
>Maybe jar files can include a META-INF/MANIFEST.MF file that lists the
>classpath path as "Class-Path" attribute?
?
[CONTRIB]
>Although the above wouldn't work with Manifest files inside the jar
>files. I assume that the update script placees the CONTRIB jar in the
>JAR list of the other package.
Yes, more or less: a second 'contrib_packagname' file with the
'update-javaconfig' comand is generated. At least with my first
implementation, which I've posted a month ago.
>> Java libraries must depend on the needed working runtime
>> environments, including the virtual package names of working
>> versions of the "unfree" bin/java interface.
>Why specify some unfree java interface versions in a Debian main policy?
Because IMO it would be unwise to prevent our packages to be used with
unfree java virtual maschines. At least until they are at least as
feature full as the 'unfree' ones.
[JNI]
>What about CNI libraries as used by gcj/gij applications?
>/usr/lib/jni seems not appropriate in that case.
>/usr/lib/cni then?
Actually I haven't heard about this feature. What is the difference?
This would mean, that the resulting package has a build and runtime
dependency on gcj/gij?
>Also note that gcj can precompile a class/package to native code to get
>optimal speed and startup characteristics. These are normally called
>org-some-package.so so they are automatically loaded if a program needs
>some org.some.package.Class if they can be found in a standard library
>search path location.
This is an optional feature and packages are free to add such libs. If
that is done, a new patch for this libs would be good (/usr/lib/gcj-lib or
so).
But please wait with this after this proposal is finished. I can't
handle that much, especially as I'm no gcj expert.
>> 2.6. Java programs
>Why depend on the java-config program and/or the bin/java unfree
>interfaces?
java-config is a easier way to setup the classpath. For the unfree
interface see above.
>gcj compiled applications for example just have to depend on the
>appropriate libgcj version they were compiled against. But can the run
>out of the box as normal native applications.
So they are normal native apps as handled by the normal debian policy.
This is the debian *Java* policy.
>Why should they build depend on unfree environments if they are part of
>main?
So that they are build'able by a user, who has just downloaded and
installed a sun virtual maschine.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: