Cris J. Holdorph writes:
> Bernd Kreimeier Writes:
> > When we can implement find etc. in pure Java, and create
> > ELF as well as a bytecode from the same Java source using
> > the basis to formulate a policy, or even plot a roadmap on how
> > Java could make binary-all grow and shrink binary-i386 & Cie.
>
> Is there a way to compile Perl to a native binary? Why do you see
> that (compile Java to a native binary) as a requirement before starting
> a Java policy? I'm curious, because if there is such a Perl utility
> I know a lot of people who would want to try it (no sarcasm, I'm serious).
> At the same time, if there isn't, I would not say the Perl policy is
> no good.
Yeah. I was sloppy there, mixing up the policy with somebodies
remark about a Java OS/environment. Native compile is certainly
not mandatory for a policy draft. It's just part of what I consider
a possible roadmap, and I think a roadmap draft should preceed
a policy draft.
> Most of your other points are good, I'm not sure I agree with them all,
> but I'd really like to see this one clarified.
Let's try it this way: Perl is a bit leaner than Java, isn't
it? I mean, the VM might be small, but, short of subsetting,
we have Sun's core class bloat, and then AWT, for a mere
runtime environment.
So, if I were to set out to write Java versions of ls, find,
tar, zip, bash, make, and at the same time implementing a
libj they share, I might want to be really sure that the
code I write is still workable w/o a Java VM. I can count
on perl fitting into small and lean installs, I can't
count on Java having a similarly small footprint.
If a purpose of Java is to move code from binary-i386 to
binary-all, it might be very handy to have the ability to
say: okay, I don't want to force Java on people, but I
want to develop in Java, so why not generate native code
from bytecode or source in binary-all if installing on
a non-Java box. dpkg could do that presuming that gcj
is working, and installed along with the rest of gcc.
This is the kind of flexibility that implementing new
tools in Java might gain us, *presuming* we have the goal
of migrating from a Java-free native to a mixed environment
(to a predominantly Java OS).
Of course, your goals might differ, and with a different
roadmap, a different policy makes sense. The question I
tried to ask when the policy proposal came up originally
was: what is your vision of "Java in Debian"? Is it just
a bunch of packages to put somewhere, a different compiler
and runtime environment to manage? Or is it an integral
part of your ideas of what free, *portable* software should
look like in 5 or 10 years?
For example, if your policy encourages GPL, it means
that we will get a lot of insular solutions, of Java
code that can't be used from non-GPL'ed applications,
as Java is always linking. If your policy wants that
reusable Java utility code is maximized, and available
to non-GPL'ed applications as well, then you need to
require LGPL licensing on code that is meant to be
"libj", for lack of a better word, and encourage
minimization of the GPL'ed main() classes.
UNIX has a filesystem standard (more or less) for native
code. Nobody has created a partially Java based UNIX yet,
so there is no standard for what goes where. But this
is not an issue of mere reg-u-lation, it is a question
of how this Java based UNIX is supposed to work,
technically, legally, practically. "Java in Debian" is
new territory - this is not taillight chasing anymore.
Not that you can't have some policy or another without
all that jazz ;-):
b.
