Re: [PROPOSAL] 3. RfD on new debian java policy
Hallo Mark,
* Mark Wielaard wrote:
>On Sat, 2003-09-06 at 19:15, Jan Schulz wrote:
>> * Mark Wielaard wrote:
>> 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.
But they can be started by ./name and not a wrapper script, which calls
java -cp ... Main. The problem in debian is to find out this java.
This should be adressed in this proposal.
>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?
Becasue the gjdocs package will do the job fast than the native
compiled gjdoc? I don't want to start a flamewar, and I haven't looked
into this *at all* (only seen a discussion about some benchmarks,
which said, that IBM java is faster than gcj).
This policy proposal does *NOT* address this issue.
This proposal tries to eliminate the problem how to get a working
"java"-command, which is able to run the java application. It also
adresses the build environemnt, so that java packages can be compiled
to java byte code and so on.
>> >> 2.1. Java virtual machines and runtime environments
>> 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.
There isn't such a package in debian. But if we want our users to be
able to use Sun/IBM virtual maschines, this should be made possible
via this interface.
I have no idea, how far you've looked into the current implemntation
to make this possible, so I just give you some of my impressions, from
packaging eclipse.
* Eclipse wasn't yet able to run with free JVM (kaffee 1.1.1 might
change that, but I haven't looked into that. gij is not AFAIK (yet))
* eclipse more or less relies on the fact, that
a) JAVA_HOME is set (can be done in a rc file in $HOME)
b) /usr/bin/java points to a possible JVM
So, this will mean, that I have to rely on the fact, that
/usr/bin/java is setup properly. I use mpkg-j2sdk to convert a -bin
download to a debian package. mpkg-j2sdk sets the priorities for the
alternatives to >1000, so its save.
As the /usr/bin/java alternative is only 'protected' by
'java?-runtime', I can't be sure, what VM I will get, when I call this
binary.
More or less, thsi results in a compelte mess. Debian is also famouse
for teh fact that, if I install a package and the packeg instaleld
correctly, this package will work. Given the above facts, this is not
working.
>> 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.
The 'unfree interface' is a way to access unfree JVM. It's also a
attempt to seperate 'incomplete' (spec and API wise) JVM from complete
ones.
Debian policy is a document, which describes debian packages and how
to create them. It does not promote anything. Getting a unfree VM
working with the packaging system *still* requires more steps than the
normal 'apt-get install <javaapp>'. Unfree JVM *are* able to run our
packages and they are 'free as in beer' for our users.
I will neither propose nor agree with a debian java policy, which will
ignore this facts and make out users patch debian packages to get this
working.
>> 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.
I think we can rely on sun, that a given version of a JVM will be
complient with the original sun one. The only 'requirement' about the
'bin/java unfree interface' is a alternative for /usr/bin/java-version.
>> >> 2.1.1. bin/java
>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.
Any proposals? IMO the above is good enough for debian java policy. As
the proposal says, /usr/bin/java is not meant to be accessed by
packages.
>> >> 2.1.3. JNI library path
>> 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?
If it does that for JNI libs, then this is unessesary on debian
systems. JNI libraries have to be placed in /usr/lib/jni.
>> 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).
If I read the RH eclipse page right, it won't work completely without
soem patches, which are not the current release. Anyway, that isn'T
the point.
If you want to advocate for more native compiled apps, please file
bugreports and patches for the corresponding packages. It should all
be possible already.
>> >> 2.2.1. Ant Environment
>> 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 I could get that going in some afternoons, but it would mean
that someone with insight into the different javadoc implemenations
needs to do the delegates. And that all means that we will introduce
some code, which will have bugs, which is not complient with the nomal
ant and so on. This changes should be done upstream, they are to big
to be handled as debian patches. And a 'debian branch' isn't that nice
as well.
Please also note, that I currently don't have this 'some afternoons'.
>> 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!
I will try to see what we can do about this. In the moment this is low
priority for me.
>> 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!
... and can't be used with the default ant, which comes with debian.
Anyway, I think I will build such a binary when I make my eclipse 3.0
move.
>> [..] 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?
ant defaults to the sun...javac.Main javac compiler implementation,
which is in the tools.jar. This means that the 'Ant unfree interface'
needs to set this. Sme with eclipse, which has to set the JARS entry
to the jar file, which includes the eclipse ant compiler.
>Then why still have the /usr/bin/javac alternative?
Because of backward compatibility (at least until the transition to a
new policy is over). Because some suers expect to see a /usr/bin/javac
command. and this is certainly good enough for HelloWorld.java. just
not enough for programms like tomcat or eclipse.
>Wouldn't it be clearer for the user if they just used the compiler that
>wanted by name?
Yes.
>> 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?
Swing? Run every program as good as the unfree ones?
Just a question: would you deploy a server, which gets full load, with
tomcat and gij or kaffe? Or even a native compiled tomcat?
>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
So that is currently a gcj only possibility? If yes, the gcj package
should deal with that. Please add a bugreport to that package.
>> 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?
To deal with java apps/libs, which comes precompiled into java byte
code.
>> 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
backporting from the unstable branch? I do that all the time. And
there are still packages out there, which do not work with free tools.
>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.
No. I use debian, because I can use the packaging system without
getting a headache. if something is possible, especially by using a
simple interface as the now proposed one, than I expect debian to make
this possible.
>They should get the upstreeam sources in that case and
>hack on those.
I'm not going to punish someone, because he has a requrement for a
unfree piece of software. Neither by forcing this user to download a
bunch of package to satisfy dependencies, which are actually satisfied
by the unfree piece of software, nor by making him to compile software
'the hard way', when this software is available by the debian
packaging system.
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: