Hi, On Sat, 2003-09-06 at 19:15, Jan Schulz wrote: > * Mark Wielaard wrote: > >I am one of the GNU Classpath developers but not a Debian developer. > > Thanks for joining anyway :) I am a Debian user though and use it for all my development machines. > >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. 'java' is a big word. Such programs still use the java programming language and a set of standard libraries. The only difference is that they don't use intermediate byte code but have a build in (by linking against libgcj) execution environment. > 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. I think it would be a good idea to set some sort of policy for this. See e.g. the two different gjdoc packages (gjdoc and gjdoc-native). Why have the gjdoc version that depends on byte code when there is already a normal native application? > >> 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. But that means that this definition is completely useless for Debian developers since there are no packages in Debian that satisfy this definition. > >> 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, [...] That says Debian acknowledges the existince of such software (a sad fact that cannot be denied), but it doesn't say that Debian should promote and advertise such things. And this unfree interface isn't even part of contrib or non-free. > I'm not happy with 'unfree interface', but thats IMO the clearest name > for this interface. I think it is irrelevant to Debian since it will never be part of Debian. > >> 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'. What do you mean 'good enough'? Good enough for what? If you insist on things supporting this unfree interface you should at least give a good definition of it in the policy so packagers can make sure they have implemented it correctly. > >> 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. A "java virtual machine" is that an interpreter for (a specific version) of java byte code? I think that although it wasn't defined in the past it should be better defined then saying that there are basically no requirements. > >> 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? Searching /lib and /usr/lib is what gcj does by default. Should this be disabled to comply with the policy? > >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. No. gij can handle interpreted and compiled classes equally well. Interpreted classes can do reflection on compiled classes and the other way around. If you ever tried out my old eclipse on gij example you will notice that although eclipse was at that time almost completely interpreted it was still not that slow (once it was loaded) since almost all classes used some pre-compiled class libraries. http://www.klomp.org/mark/gij_eclipse/ > Also: gcj isn't that far in debian). All the above should work out of the box on a Debian unstable system (which comes with gcj-3.3.2 - pre-release). Just cvs checkout rhug and do a ./configure && make. (And I should have added that it also contains: gnu.readline, log4j, oro, struts, tomcat, jython and mx4j). > >> 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 don't think this will be that hard. But then again I am not a Ant hacker. > 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 :( A test-suite would be ideal! > >> 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. rhug (yes, I am a big rhug fan) comes with a native eclipse compiler (ecj) which is faster then jikes! > [..] 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. Yuck. What does this tools.jar provide? > >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. Then why still have the /usr/bin/javac alternative? Wouldn't it be clearer for the user if they just used the compiler that wanted by name? > >> 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. Same comment as above then. Why provide it at all in that case? > >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. OK. > [java-config proposal] > >Maybe jar files can include a META-INF/MANIFEST.MF file that lists the > >classpath path as "Class-Path" attribute? > > ? It is a way for a jar file to declare on which other jar files it depends. But as you explained below the update script approach is probably more flexible. > >> 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. What features do you miss that you think are essential? > [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? Yes. The CNI interface is a way to easily combine code written in java and C(++) when compiled with gcj. It makes sure that C++ classes and java classes can easily call each other methods and access each other fields without having to go through all the lookup methods that JNI demands. See http://gcc.gnu.org/onlinedocs/gcj/About-CNI.html > >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. OK. But for people that are curious it is documented at: http://gcc.gnu.org/onlinedocs/gcj/Extensions.html > >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. Then what precisely is the goal of the *Java* policy? It seems all it want to do is make debian developers go out of their way to make things work with some proprietary tools. > >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. Why should they want to build the debian packages with those tools? The Debian packages have been prepared to build with the tools that Debian provides. If users use some other tools then Debian should not make that imposible, but then they cannot depend on being able to easily rebuild the packages. They should get the upstreeam sources in that case and hack on those. Cheers, Mark
Attachment:
signature.asc
Description: This is a digitally signed message part