To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=46241
                  Issue #:|46241
                  Summary:|OpenOffice.org should run fully on an open source
                          |Java implementation (e.g., gcj, Kaffee)
                Component:|tools
                  Version:|OOo 2.0 Beta
                 Platform:|All
                      URL:|
               OS/Version:|All
                   Status:|UNCONFIRMED
        Status whiteboard:|
                 Keywords:|
               Resolution:|
               Issue type:|DEFECT
                 Priority:|P4
             Subcomponent:|code
              Assigned to:|mh
              Reported by:|dwheeler





------- Additional comments from [EMAIL PROTECTED] Tue Mar 29 16:28:57 -0800 
2005 -------
(This is a proposed tracking bug for work that's already ongoing to make
OpenOffice.org run on open source software Java implementations.  This work has
been ongoing with lots of successes, but that work doesn't seem to be visible to
a lot of people who want it to happen.  With this tracking bug, people can point
to this issue id whenever the subject of "I want to run OpenOffice.org on an
open source Java implementation" comes up.  This tracking bug also makes it
possible to post successes or patches to actually DO this, instead of just
complaining about it.)

<p>
As I'm sure you're aware, many people really want OpenOffice.org
to run on an open source software / Free software (OSS/FS) Java implementation,
without loss of functionality.
For both people who don't already know :-), see
<a href="http://software.newsforge.com/article.pl?sid=05/02/25/209222";>this
review</a>,
<a href="http://software.newsforge.com/article.pl?sid=05/03/22/204244";>
Bruce Byford's commentary,</a>
and
<a href="http://developers.slashdot.org/article.pl?sid=05/03/28/2218246";>
Slashdot discussion</a>, as well as the essay
<a href="http://www.gnu.org/philosophy/java-trap.html";>the Java trap</a>.
Marco Fioretti worries that the increased dependency on Java may destroy the 
project's credibility, and
several are considering NOT promoting it.
It certainly causes portability problems.
Many Linux distributions (Fedora Core, Debian, Ubuntu, etc.) will not
include anything that requires non-free components in their core,
limiting OpenOffice.org's use.
For many architectures, Sun's JVM is simply unavailable, limiting portability.
It also causes installation complications -- now you need to
install a JVM, as WELL as the program you actually wanted --
on many platforms.
Many see no point to an open source software program running on a proprietary
Java Virtual Machine; the result is still proprietary, and there are already
several proprietary programs that work as office suites.
Even without the concerns about freedom, it's reasonable to want more than one
implementation of a key component in case something breaks; the IETF asks for
multiple implementations of specs to ensure that their weaknesses get wrung out.

<p>
However, there's been a lot of ongoing work to
<a href="http://tools.openoffice.org/";>make Openoffice.org run
on OSS/FS Java implementations</a>.
In particular, Red Hat sponsored work has had a lot of success
getting the Java portions to run on gcj plus Classpath;
<a href="http://gcc.gnu.org/ml/java/2005-01/msg00023.html";>
success for the critical portions was reported in January 2005</a>, and
<a href="http://blogs.linux.ie/caolan/2005/03/10/latest-gcj-and-ooo2-update/";>
by March 2005 even more success was reported</a>.
Note that <a href="http://klomp.org/mark/gij_eclipse/";>
Eclipse is already running on open source Java implementations</a>
so this isn't as far off as it might appear.

<p>
There are many issues that are related to this, but aren't the same thing.
Issue #45709 asks to limit JRE use -- but for many, the goal isn't to limit Java
use necessarily, it's just to ensure that OpenOffice.org runs on at least one
open source software JVM.  (Though if avoiding certain JRE uses helps to meet
that goal, then that's one solution.) This is related to Issue #44283 (run on
Kaffe), but not the same -- running on Kaffe would meet the goal, but it's not
necessary, and most ongoing work to meet this issue is actually using gcj not
Kaffe (though once it ports to one, it'd probably be easy to do the other). This
is related to issue #45925, but that is simply a patch to greatly increase speed
of compilation for Java for an OSS/FS Java implementation -- not to ensure that
it runs on an OSS/FS Java implementation.

<p>
This may affect how some things are done.  For example, issue #37399 recommends
the use of some Java features that may not be implemented in all Java Virtual
Machines... so perhaps that work should be delayed until at least one other
implementation is available to do it.
It might be useful to formally include an OSS/FS Java implementation in the test
suite, and/or encourage developers to either avoid functionality not available
in an OSS/FS Java implementation (particularly the Classpath library) OR to use
it only after helping to implement that functionality in an OSS/FS
implementation such as gcj, Kaffe, or Classpath.

<p>
Anyway, I hope this proposed tracking bug helps track the issue for those who
are interested in it.

---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to