Bug 506332
| Summary: | depends on java-gcj | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Juha Tuomala <tuju> |
| Component: | lucene | Assignee: | Deepak Bhole <dbhole> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 10 | CC: | caolanm, dbhole, rdieter |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-06-16 19:25:32 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Juha Tuomala
2009-06-16 18:03:05 UTC
The dependency on GCJ currently exists because there are ahead-of-time compiled pieces in the lucene rpm. These are needed to ensure reasonable speed on platforms without a JIT[1] (from IcedTea). We are working on a better solution that uses IcedTea code + Shark/Zero[2] to replace GCJ. When the decision to remove GCJ is made, the dependency will go away automatically. 1: http://en.wikipedia.org/wiki/Just-in-time_compilation 2: http://today.java.net/pub/a/today/2009/05/21/zero-and-shark-openjdk-port.html (In reply to comment #1) > The dependency on GCJ currently exists because there are > ahead-of-time compiled pieces in the lucene rpm. These are needed to > ensure reasonable speed on platforms without a JIT[1] (from IcedTea). > We are working on a better solution that uses IcedTea code + > Shark/Zero[2] to replace GCJ. When the decision to > remove GCJ is made, the dependency will go away automatically. Thank you for clarification, this gives the clear picture about the situation. Unfortunately the whole proved to be even more bloated than I expected, all that (shark/zero text) going inside wordprocessor is a scary thought. Why can't they use the C++ implementation of lucene in OOo? That is certainly a possibility. I am not knowledgeable enough on that front to know all the technical issues though. Adding Caolan to cc. He is the maintainer of the OpenOffice.org packages and can comment.. http://qa.openoffice.org/issues/show_bug.cgi?id=83625 'lucene4c is dead anyway: "2006-10-15 - Project closed due to lack of activity"' I fixed the whole help thing at one stage to no longer need Java during the build process back when we were using a C++ help engine and just Java for preprocessing. Then the decision was made to use lucene as the new help engine and Java was put back in for both the preprocessing and runtime. If anyone wants to port OOo's help over the lucene4c that'd be groovy, especially for build time. But the core of *this* issue is the continuation of aot-compiling with gcj and packaging aot libs by default which forces the java-gcj stack onto all installs when a java package with aot libs in it is intalled. So moving OOo off java lucene won't help that as the same thing would just happen with another java dependency of OOo, or indeed of nearly everything else in Fedora. Ideally we'd bite the bullet on this and not aot anything any more, or at the least only aot for platforms where the jit is considered too sluggish. |