Bug 504891 - Review Request: trove - Efficient Java collections
Review Request: trove - Efficient Java collections
Status: CLOSED DUPLICATE of bug 532521
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-06-09 18:47 EDT by Jerry James
Modified: 2009-11-17 05:29 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-11-17 05:29:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jerry James 2009-06-09 18:47:20 EDT
Spec URL: http://jjames.fedorapeople.org/trove/trove.spec
SRPM URL: http://jjames.fedorapeople.org/trove/trove-2.0.4-1.fc10.src.rpm
Description: The GNU Trove library has two objectives:
- Provide "free" (as in "free speech" and "free beer"), fast, lightweight
  implementations of the java.util Collections API.  These implementations
  are designed to be pluggable replacements for their JDK equivalents.
- Whenever possible, provide the same collections support for primitive types.
  This gap in the JDK is often addressed by using the "wrapper" classes
  (java.lang.Integer, java.lang.Float, etc.) with Object-based collections.
  For most applications, however, collections which store primitives directly
  will require less space and yield significant performance gains.
Comment 1 Jason Tibbitts 2009-06-11 15:51:59 EDT
Any comments on the conflict between this and ESR's Trove project?  http://catb.org/~esr/trove/

Is the other project sufficiently dead that this isn't an issue?  Even this project's upstream seems to use "trove4j" in places.
Comment 2 Jerry James 2009-06-11 15:56:31 EDT
I don't know anything about that other Trove project, but it sure appears to be dead.  It's developer mailing list doesn't even exist any more.  However, I'm all for avoiding name conflicts.  Should I call this submission "trove4j", do you think?
Comment 3 Jason Tibbitts 2009-11-10 15:08:30 EST
*** Bug 532521 has been marked as a duplicate of this bug. ***
Comment 4 Guido Grazioli 2009-11-10 19:37:09 EST
I'm interested in this package, Jerry are you still working on it?
Some quick things:
- renaming to trove4j seems reasonable (other distros did that also)
- prefer %global over %define
- group Development/Libraries/Java is not standard, change it to Development/Libraries
- -javadoc subpackage should Requires: jpackage-utils too
- would packaging lastest stable ver 2.1.0 be feasible?
- as per gcj guidelines, in %%files:
%if %{with_gcj}
- %{_libdir}/gcj/%{name}
+ %attr(-,root,root) %{_libdir}/gcj/%{name}
Comment 5 Jerry James 2009-11-12 18:16:32 EST
Actually, my reason for wanting this package in Fedora vanished a couple of months ago.  I'm still willing to see it through if nobody else wants to so do, but if someone else is interested in maintaining, I'm happy to pass the baton.

Otherwise, I'll fix the problems noted in comment 4 sometime in the next 24 hours or so.
Comment 6 Mary Ellen Foster 2009-11-16 16:26:54 EST
I have a package-in-progress of version 2.1 in bug 532521 if anyone's interested -- Jerry, do you still want to package this?
Comment 7 Jerry James 2009-11-16 16:39:50 EST
Not really.  The package I wanted to push that depended on this turned out to have some severe license problems.  Please go ahead and take it.  I'm not sure what the proper bugzilla etiquette is, though.
Comment 8 Mary Ellen Foster 2009-11-17 05:29:34 EST
How reversing the "closed duplicate" direction of the two bugs?

*** This bug has been marked as a duplicate of bug 532521 ***

Note You need to log in before you can comment on or make changes to this bug.