[kaffe] Re: OpenOffice?
robilad at yahoo.com
Mon Jul 1 02:08:12 PDT 2002
--- Jim White <jim at pagesmiths.com> wrote:
> Rene Engelhard wrote:
> > Jim Pick wrote:
> >>Here's a little project for somebody.
> >>I don't have time to look at it, but it would be
> nice to know if Kaffe
> >>could be used instead...
> Well, I assume you mean "little" in jest.
> Building OpenOffice is never a small thing (the full
> build runs about 20
> hours). It has 109K lines in 482 files of Java
somene has tried with an older version of kaffe and
> Anyhow, the following is a list of the "import"
> lines from OpenOffice
> 1.0 source. This build assumes JDK 1.3, and they
> are moving (or have
> already) to conditionally support JDK 1.4 for the
> Accessibility API.
> import com.jclark.xsl.dom.Transform;
we can run the xsltmark benchmark with all major java
xslt processors, so that implies that the xml/xslt
processing machinery will work. note that we use the
usual (eventually non-free) components to do so, we
don't reimplement jaxp for example.
> import com.sleepycat.db.*;
I don't know what it is, it seems to be open source,
> import com.sun.jini.admin.DestroyAdmin;
there is no free software implementation of jini, as
you can't implement it without violating sun's patents
> import java.security.Identity;
not there yet. I have an implementation ready to be
checked in, but I'm waiting for 1.0.7 to be released,
as it's not really a build issue.
kaffe has its own implementation of servlets, i think.
but you can use tomcat 3.2.4 with it anyway, so that
there is no free software version of swing. the
classpath developers are working on it, but aren't
done yet, as far as I know. kaffe does not have it,
but works well with sun's swing 1.1.1 FCS, which is
not free software.
they should really use java.sound for that. or jmf.
Anyway, it won't work on kaffe as we don't implement
any sun.* classes. They are not documented after all,
and not part of the API.
Not implemented and most probably won't be. These are
the JDK 1.1 undocumented (actually sun mentions them
in an example in the java security architecture paper,
but explicitely recommends staying away from it) key
management apis. Sun has deprecated the corresponding
classes in java.security with java 1.2, and uses
different key management facilities. Open office
developers should know better, as they are supposed to
be using java 1.3, right? ;)
[lots of other imports of sun.* and sunw.* classes]
Anyone using sun.* classes doesn't _want_ to be
portable accross VM releases/implementations. Someone
(either the open office developers, or the debian
developers wanting to build open office using free
software) should clean up the sun.* mess. I wouldn't
want to implement sun.* classes just to suit someone
else's bad programming style, and I don't know anyone
who does ;)
Beside that, the most ugly problem with building open
office using free software is jini. That won't happen
as long as sun can sue anyone writing a free
implementation by the spec for IP violation. No legal
security -> no free implementations.
All of the above is valid as long as the apis I picked
on are required to build open office. If you can
configure it to build without them, then the problems
above don't play a large role.
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
More information about the kaffe