Debian Java outlook/ Re: kaffe orphaned?

[Bernd Kreimeier <bk@gamers.org>]

Mark W. Eichin writes:
 > [goes back to lurking until free-java is good enough to consider as an
 > *only* java environment :-)]

Yeah. It's not only that we'd need an LGPL'ed VM and core
classes, and a GPL'ed compiler. I tried to make this point
last year that we would need some kind of experimental
setup prior to laying down an actual policy. Issues like:

   - defining a Java equivalent to libc 
      (collection of utility classes shared among Java "binaries")
   - a good way to wrap utility classes by main()
      (to implement "jls", "jfind", "jtar" etc. w/o
        piling up GPL'ed special case code)
   - an Echidna-like Java service that allows for using
      small Java proglets like "ls" inside a native
      environment w/o starting a VM for each
   - a pure Java built environment that works with just a
      JRE under Win32 just as well as it does under Linux
   - a free compiler to convert pure Java source or "binaries"
      to C or native binaries competitively (size, overhead)

I somewhat think we should decide on how we see Java used
in Debian first, before defining a policy. binfmt for scripts
alone isn't sufficient as support. I see Giant Java Tree
collections on one end, and JOS on the other, but somehow, 
there is no intermediate target - that is, a pure Java 
toolbox that is seamlessly and efficiently integrated into 
a native Linux environment. Just piling up more *.deb packages 
won't solve this. Implementing Java Bash doesn't solve this
either - Java has to work from the native commandline in a
way that I can replace builtin commands and ELF binaries
with calls that execute bytecode, and the base penalty is
just one instance of a VM present like e.g. the X server.

When we can implement find etc. in pure Java, and create
ELF as well as a bytecode from the same Java source using
free tools, when we can execute nfind and jfind as quickly 
and efficiently as /usr/bin/find, when Find.java uses
a FindOperator class that can be used in JDepend, JMake
and any program (practically, and legally), then we'll have
the basis to formulate a policy, or even plot a roadmap on how
Java could make binary-all grow and shrink binary-i386 & Cie.


                                           b.


P.S.:
 > thumbs up for answering the question, thumbs down for *answering*
:-)