Issue 46241 - should run fully on an open source Java implementation (e.g., gcj, Kaffe)
Summary: should run fully on an open source Java implementation (e.g., ...
Alias: None
Product: Build Tools
Classification: Code
Component: code (show other issues)
Version: OOo 2.0 Beta
Hardware: All All
: P4 Trivial with 11 votes (vote)
Target Milestone: ---
Assignee: Martin Hollmichel
QA Contact: issues@tools
Depends on:
Reported: 2005-03-30 00:28 UTC by dwheeler
Modified: 2013-08-07 15:34 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description dwheeler 2005-03-30 00:28:57 UTC
(This is a proposed tracking bug for work that's already ongoing to make 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 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.)

As I'm sure you're aware, many people really want
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="">this
<a href="">
Bruce Byford's commentary,</a>
<a href="">
Slashdot discussion</a>, as well as the essay
<a href="">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'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.

However, there's been a lot of ongoing work to
<a href="">make 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="">
success for the critical portions was reported in January 2005</a>, and
<a href="">
by March 2005 even more success was reported</a>.
Note that <a href="">
Eclipse is already running on open source Java implementations</a>
so this isn't as far off as it might appear.

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 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.

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.

Anyway, I hope this proposed tracking bug helps track the issue for those who
are interested in it.
Comment 1 Martin Hollmichel 2005-03-30 08:20:34 UTC
confirming issue. set target to OOo PleaseHelp. a few remarks:

I suggest to change the title from " should run fully on an open
source Java implementation (e.g., gcj, Kaffee)" to "OOo should support all
compatible Java implementations (e.g., gcj, Kaffee)" for obviuos reason.

Also "For many architectures, Sun's JVM is simply unavailable, limiting
portability." is not the point since OOo is not limited to run with Sun's JRE.
Therefore we agreed in
to - 1: the Java baseline is 1.3.1
- 2: only official Java APIs are allowed to be used
- 3: Java JRE interested parties provide the support code and take care 
of QA, bugs etc.
- 4: OOo Java implementations must be encapsulated with well specified APIs
- 5: OOo Java implementations must not check against Java versions or 
vendors, with the only exception of workarounding bugs
- 6: OOo Java implementations must not use swing, either because no free 
swing implemetation is available or because it makes the user interface 
inconsistent, this rule might be relativated in respect to 4

Java 1.3.1 is available for many platforms from different vendors, so
portability should only an issue for very few platforms.
Comment 2 dwheeler 2005-03-30 15:43:55 UTC
I agree with you that "For many architectures, Sun's JVM is simply
unavailable, limiting portability" isn't really the main point.
Please ignore that sentence.

But I don't think the title should be changed. I really
think the title emphasizes the key issue, as captured by
the various news articles about OOo. Sure, it'd be great if OOo
supported "all compatible Java implementations (e.g., gcj, Kaffee)",
and that's a great long-term goal.
But here's why I think that should be considered a separate issue,
and that the more immediate issue is support by at least
one OSS/FS Java implementation:
1. Right now, I think OOo doesn't completely support ANY alternative
   Java implementations (though it's getting really close).
   Once it supports ONE OSS/FS alternative, I think it'll be easier to
   support MORE than one alternative, because a lot of the issues
   of unsupported libraries, unintended assumptions, etc. will have
   been worked out.  So you could add your wider goal then.  But it'd be
   easier to "walk before you run" -- make the goal ONE other
   OSS implementation for now, and then add the larger goal later.
2. If OOo supported 10 other proprietary Java implementations, and
   no open source Java implementations, the issue would still arise.
   If it supported one open source implementation, and no others,
   many people would still be happy.  Yes, many would want to go
   beyond that, but that'd be the step at which many complaints
   would disappear.
3. Whether or not the implementation is completely "compatible"
   isn't the issue.  Kaffe and gcj are known to only be partly
   compatible, in the sense that some libraries are not completely
   implemented (technically by classpath, since both use classpath).
   Granted, the areas that are incomplete are smaller now. But
   the solution isn't to ignore Kaffe or gcj; the
   solution in some cases may be to avoid using certain functions
   in OOo so that OOo will run on them (OOo already does this,
   with its policy to avoid Swing for that reason). Another solution may
   be to work with the Java implementation to add the missing function,
   or to implement the function inside OOo's codebase even though
   there's an "official" API that does it.
   But don't limit running OOo to "compatible" implementations;
   an OSS/FS implementation that's incomplete, but runs OOo, would
   meet this proposed bug tracker.

Thanks for the reference to this useful statement:

Comment 3 Mathias_Bauer 2006-12-08 10:49:03 UTC
I hope that the recent development of Java will make this issue obsolete.
Beside that: to my knowledge we currently don't have any Java components in OOo
that are not running with gcj. Or am I wrong?!
Comment 4 rene 2006-12-08 10:59:21 UTC
mba: you're partly wrong.

com/sun/star/lib/sandbox/   @echo This dir cannot be build with gcj 
because of sun.applet.AppletAudioClip

of course, "sandbox" is obsolete anyway, but that's random example. which I 

And, most importantly:
(last comment...)
Comment 5 rene 2006-12-08 11:01:51 UTC
and yes, I hope that OOo will build with the free Java. Then this issue is not 
obsolete, though, since people should have choice what they use. But it might 
fix the pressing problems like the form wizard (will the JDK 6/7 also contain 
the sun.* clases?)
Comment 6 sparcmoz 2006-12-08 11:14:50 UTC
I could never get the agenda wizard running on GNU/Linux SPARC with gcj - did anyone fix that with gcj?
Comment 7 dwheeler 2008-05-05 17:31:00 UTC
As Sun has released (most of) its Java implementation as open source software,
this is probably resolved.  Can anyone confirm, and if so, close this?
Comment 8 Martin Hollmichel 2008-05-05 19:27:42 UTC
I think we should keep this issue open until there is a final release available,
but you're right, moreorless this issue has been addressed by GPL'd Java version.
Comment 9 Martin Hollmichel 2008-09-01 19:28:40 UTC
mark issue as fixed, OOo runs now with gcj, openjdk, available in the meantime
with most linux distros.
Comment 10 mechtilde 2008-11-08 22:49:47 UTC
Comment 11 mechtilde 2008-11-08 22:50:10 UTC
-> closed