Re: [PROPOSAL] 3. RfD on new debian java policy
--- Mark Wielaard <mark@klomp.org> wrote:
> > 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.
I have the impression that you two will have a lot of things to talk about when
it comes to packaging eclipse for free VMs ;)
> > 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.
Unfortunately, I don't have the test URL handy, but yes, the kaffe regression
test reporting server will run on kaffe 1.1.1 and jetty. Jim Pick (kaffe's
project leader) is working on it, and seems to be quite happy about it.
Just for reference, as Jan seems to have the impression that free java
environments have inferior performance compared to unfree ones, freenet
developers are very keen on running freenet on kaffe again, as its efficient
threading and native support for big integers let it outperform unfree
solutions for running freenet at least. Currently freenet uses some NIO
features that are not available in kaffe yet, but kaffe and gcj developers are
collaborating on an implementation for GNU Classpath.
> > >> 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.
Java bytecode by itself is a quite convenient mechanism for cross platform
distribution of executable code, but if you can have better performance through
compilation to native code, why not use and encourage it?
As an aside, to show where the free java environments are heading to, I'd like
to point out, that kaffe will eventually move to using a gcj-precompiled class
library like gij, with efficient jitters on top of it instead of re-jitting the
core class library on every startup as it does now. Some kaffe developers also
want to investigate adding persistency mechanisms to the jitter, to avoid the
cost of re-jitting as much as possible. We'll be embracing gcj instead of
fighting it ;)
> > >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.
Who knows, one day I may end up being a Debian developer instead of just being
a user, and then I don't want to have to install non-free software to make sure
that my packages work with it, because of a policy that mandates using non-free
sowtware as the easy way to interoperability.
That would be like requiring that C programs build with Borland's C/C++
compiler running on wine just because a lot of people used to use Borland's
compilers on MS DOS back in the 90s ;)
cheers,
dalibor topic
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Reply to: