Hi, I am one of the GNU Classpath developers but not a Debian developer. On Sat, 2003-09-06 at 01:47, Jan Schulz wrote: > Chapter 2. Policy > > Packages written in Java are separated in two categories: programs > and libraries. Programs are intended to be run by end-users. > Libraries are intended to help programs to run and to be used by > developers. > > Both are shipped as Java bytecode (*.class files, packaged in a > *.jar archive) and with an "Architecture: all" since Java bytecode > is supposed to be portable. It may additionally be shipped as > machine code, as produced for example by the GNU Compiler for Java, > in a separate architecture-specific package. 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. > 2.1. Java virtual machines and runtime environments > > Java virtual maschines and java runtimes environments are tightly > linked, so it makes no sense to seperate them. Therefore only the java > runtime environment is used to describe the command java. > > As it is nearly impossible to treat all java virtual maschines the > same, JVMs are seperated into two kinds: sun compatible and not. How is sun compatible defined? What specs should a vm/runtime implement to be regarded sun compatible? > 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? > 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? > 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. s/comand/command/ What should a package satisfy to be able to provide java2-runtime? > All java virtual maschines must setup a dir struckture in > /usr/lib/name (where name is the version of the virtual maschine) > with this content: bin/java, which is a symlink to the virtual > maschine binary. They must set the java.home property to > /usr/lib/name. > > All java virtual maschines must depend on java-common. What does java-common provide? > 2.1.2. bin/java "unfree" interface I would remove this section if you include it in Debian main. > 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? > 2.2. Java Development Tools > > As there is almost no control over different java compilers, package > should only use ant to compile and build java packages, but not > javac directly. The ant build.compiler is handled via the > java-config system (see below). For java development kits, which > aren't distributable by debian the "unfree" interface for ant > environments should be used. Ant is used by some packages, but why mandate that ant must be used? 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. > 2.2.1. Ant Environment > > Packages, which can be used with ant to compile java code must setup > a directory structure in /usr/lib/name (where name is the name of > the corresponding virtual maschine (see above)), which includes > bin/javadoc, which should be of the same API version as the virtual > maschine, includes and includes/linux, with the JNI header files. 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. > 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? 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). > 2.2.2. Ant environment "unfree" interface I won't include thesee unfree interface section in a document that goes into Debian main. > 2.2.3. javac and javadoc tools > > Packages, which include a Java compilers may provide java2-compiler > in which case they must setup a alternative for /usr/bin/javac and > its manpage. They must depend on java-common. What does it mean to provide java2-compiler? Are there any special input/output files and/or command-line arguments that must be supported? > 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? For both these alternatives wouldn't it be better to just recommend just one free application for compiling and generating javadoc? > 2.3. Java Browser Plugin > > If a package provide a Browser plugin, it needs to setup a > alternative for /usr/lib/mozilla/plugins/javaplugin_oji.so and > provide java-browser-plugin Aside. Is gcjwebplugin packaged for Debian? http://www.nongnu.org/gcjwebplugin/ > 2.4. Classpath > > To make classpath issues as easy as possible, each package, which > includes public (library) jar files must add a java-config file in > /var/share/java-config and place this jars in /usr/share/java. The > java-config file must be named the same as the package, which > contains it. Example: libant1.5-java includes the java-config file > /var/share/java-config/libant1.5-java 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. > If more than one package includes certain functionality/API, this > packages should use a agreed upon virtual package name and the > alternative system to handle the java-config file with that name. > > A java-config file is a sh compatible file, which only sets > variables. It must set JARS and DEPENDS, even if they are empty. It > may also add CONTRIB. ANT_BUILD_COMPILER, and every variable > beginning with "JAVA_" are reserved. Other variables may be used > privatly. > > The content of a java-config file is as follows: > > * JARS must be set with all public jar files, seperated by > ':' > JARS="/usr/share/java/first.jar:/usr/share/java/second.jar > " > > * DEPENDS must be a space or ':' seperated list of packages, > which this jar needs to have on the classpath at runtime. > DEPENDS="otherpackage-java libant1.5-java" Maybe jar files can include a META-INF/MANIFEST.MF file that lists the classpath path as "Class-Path" attribute? > * CONTRIB is a likewise list o packages, to which classpath > this jars should be added (plugin system). Example: a > package adds a task to ant. This package would then set > CONTRIB="libant1.5-java". > * Packages, which have contributed their jars to other > packages need to call the appropiated update-* script in > the postrm (in case of removal) and postinst (update and > install) scripts. 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. > 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? > Some Java libraries rely on code written in a "native" language, > such as JNI (Java Native Interface) code. This native code is > compiled into separate dynamic libraries which are loaded by the > Java virtual machine at runtime. > > If a Java library relies on native code, the dynamic libraries > containing this compiled native code should be installed into the > directory /usr/lib/jni. These dynamic libraries should be shipped in > a separate architecture-specific package named libXXX[version]-jni. > The package containing the Java bytecode (generally > libXXX[version]-java) should depend on this package. What about CNI libraries as used by gcj/gij applications? /usr/lib/jni seems not appropriate in that case. /usr/lib/cni then? 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. > 2.6. Java programs > [...] > java-common includes the java-config programm, which should be used > to setup the CLASSPATH environment variable. > [...] > Programs must depend on the needed runtime environments, including > working versions if the bin/java unfree interfaces. Why depend on the java-config program and/or the bin/java unfree interfaces? 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. > As "unfree" virtual maschines of a certain version almost certainly > will run code developed for this version, all packages must also use > kown working "unfree" interfaces, when they search for a possible > java binary. Other java virtual maschines should be used as tightly > as possible (use /usr/bin/kaffe-1.1 instead of /usr/bin/kaffe). Again. How are there known working "unfree" interfaces defined and should they actually be specified in a Debian main policy file? > 2.7. Building Java packages > > A package should use ant to build a package and build depend on the > required ant environments, including virtual packages for the > "unfree" environments. They should use /usr/bin/java-config to > access this ant build environment. Why should they build depend on unfree environments if they are part of main? Cheers, Mark
Attachment:
signature.asc
Description: This is a digitally signed message part