Hi Jan,
On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
> The problem in debian is to find out this java.
> This should be adressed in this proposal.
Why this fixation on this one program name?
I know there is a non-free environment called java that is a
interpreter, byte code definition, class library specifications,
development tools (RMI compiler, jarsigner, api documentation generator,
etc) language to write programs in, native binary linking (JNI) etc.
Since I have been working for a couple of years on free alternative for
a part of this (GNU Classpath concerns itself only with what we call
core classes that are essential for such an environment) I know that
there is much work to do if we want to have a completely similar set of
things. I personally think that trying to match this piece by piece,
library by library, spec by spec will not buy the free software
community that much.
I do think that it will be nice to have an free environment that is
similar enough and provides similar tools (and hopefully better improved
variants) that can be used by people to produce new exciting free
software applications or to migrate away from these proprietary tools.
And I think we have much of that already. I hope that debian
concentrates on this migration path.
> >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).
Having benchmarks helps (although you should always verify what they
exactly mean). I made some benchmarks recently for the free VMs out
there: http://www.klomp.org/mark/free-vm-benchmarks/
It doesn't benchmark any proprietary tools, but it contains links to
some benchmarks that do like: http://www.spindazzle.org/benchmarks/
Which shows that gcj is at least comparable with (and sometimes much
faster then) the proprietary VM from IBM.
> 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.
Which is a good goal. But I am puzzled why you think you need to
recommend and advocate proprietary tools for that.
> 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))
CVS and 1.1.1 definitely improves on that:
http://www.klomp.org/mark/kaffe-eclipse.html
(Thanks to Helmer Kreamer! Not perfect and not as usable as with gcj,
but at least it starts up.)
> * 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
Not if you use the native gcj version. In the past I got Eclipse working
with gij (interpreted) http://www.klomp.org/mark/gij_eclipse/
All patches, except for disabling the byte code verifier are already
included in gcj 3.3, which Debian unstable ships. It must be possible to
come up with a patch for gij to disable the byte code verifier through
the command line.
And the (fast) native eclipse can also run on Debian as I showed in:
http://lists.debian.org/debian-java/2003/debian-java-200309/msg00056.html
(Yes, you need some unpackaged gcj for that, but gcj 3.4 which will be
released in a couple of months will have all the needed patches.)
I agree that Eclipse needs to have some patches to work nicely with
alternative java like environments, but most of it works out of the box
with gcj and kaffe now.
> 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.
This looks like a problem only made worse by the java-policy since that
says that there must be a /usr/bin/java program. Normal packages should
not rely on that and should work out of the box when installed. I don't
completely follow why you think that installing some random proprietary
non-free, non-debian package will suddenly break normal packages unless
those packages have bugs (like depending on /usr/bin/java while they
shouldn't).
> 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.
Which is a silly separation. There will never be "complete" free ones if
you insist that complete means precisely like the one and only
proprietary one.
> 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.
I don't see the point of making a policy that says that packages must
work with some non-packaged non-free programs. It would be nice if they
do, but requiring it is a lot to ask of a packager.
> >> >> 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.
I propose to not define it in the policy at all.
Except maybe as a note saying that in the past there was a alternative
system for /usr/bin/java and /usr/bin/javac but it didn't work out.
> >> >> 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.
OK. That should be easy to do for gcj/gij.
> >> >> 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'.
Fair enough. But these are things that should be discussed with upstream
to make Ant usable on a Debian system.
As far as I know there are only two free javadoc like systems.
gjdoc, which is already packaged for Debian.
And sinjdoc <http://cscott.net/Projects/GJ/#sinjdoc> which I haven't
tried out yet.
And of course there is doxygen which has a completely different
interface, but which works wonderfully for java source files.
> >> 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?
I don't recommend people use Swing when developing free programs. There
are multiple alternative libraries available that integrate much better
with a typical GNU/Linux system that can be used like java-gnome
(packaged for Debian and used by my own program
<http://www.klomp.org/snark/snark-gnome.html>), qt-java
<http://developer.kde.org/language-bindings/java/qtjava.html>, simple
AWT (for GNU Classpath and gcj this will hopefully soon include java-2d
like implementations, see
http://people.redhat.com/graydon/native-java2d-aug28-2003.png) or SWT
(also bundled with Eclipse).
For GNU Classpath we don't have any real plans on creating javax.swing
like classes. We have some of them and a lot of stubs, but no concrete
plans on how and when to implement which parts of it.
> Run every program as good as the unfree ones?
Every program :) Maybe we could start with a subset of that.
What doesn't run satisfactory for you?
> 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, why not?
Maybe Dalibor has an example of kaffe.org which I believe runs Jetty on
kaffe.
> >> 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.
OK. Then I partly misunderstood. I had hoped as Dalibor said in another
thread that the Debian java-policy would explain:
From debian I'd expect a policy that helps and guides java
apps/libs/jvm maintainers to build and package their stuff with
a focus on free VMs, gives pointers who to get in topuch with if
things don't work, has a section on free java developers working
on providing a free java infrastructure and how to contribute to
it, and provides the necessary bits of information on how to
deal with the legacy, proprietary VMs. Certainly not the other
way round ;)
Dealing with java-byte-code is also not very interesting since I think
something like gcj can give users of free systems like Debian a much
better java language programming experience. But I am certainly biased.
> >> 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.
But if they are packaged for Debian cann't you just backport the build
tools also? And packages out there which do not work with free tools are
probably not packaged for Debian anyway since they would have to go into
non-free or contrib.
> 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.
I do expect Debian to have a packaging system that won't give me
headaches. And I know that is does have that. But I don't expect debian
to promote a non-free proprietary interface. Especially if I don't find
it simple at all. I still don't understand how this interface is
defined. All I see is some hand-waving and pointing to some
(unversioned) proprietary package.
> >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.
I just hope that you don't punish the Debian packagers that want to just
package some things which happen to be written in the java language by
requiring them to be interoperable with some unpackaged, non-free,
proprietary stuff. But I am not a Debian developer so I cannot judge
whether or not this java-policy is an improvement to the old situation.
Cheers,
Mark
Attachment:
signature.asc
Description: This is a digitally signed message part