Discussions

News: Jakarta Team Releases New Jakarta Commons Primitives Package

Bookmark and Share Get thread feed

  1. Jakarta Team Releases New Jakarta Commons Primitives Package (14 messages)

    • Posted by: Dion Almaer
    • Posted on: November 10 2003 10:31 EST
    The Jakarta Team has released a new package, Jakarta Commons Primitives. Primitives provides a collection of types and utilities optimized for working with Java primitives (boolean, byte, char, double, float, int, long, short). Generally, the Commons-Primitives classes are faster, smaller and easier to work with than their purely Object based alternatives.

    There are other packages out there that aim to do the same thing as Commons, such as Trove (http://trove4j.sourceforge.net).

    How many people use specialized versions of our standard Object based Collections? Do you dive for an IntList?

    At least with the Generics support in JDK 1.5, we won't have to worry about the ugly casting anymore.

    Downloads

    * Binary:
    http://jakarta.apache.org/site/binindex.cgi>#commons-primitives

    * Source:
    http://jakarta.apache.org/site/sourceindex.cgi#commons-primitives

    For more information on Jakarta Commons Primitives, see the web site at http://jakarta.apache.org/commons/primitives.

    Related Jakarta News

    The POI Team is proud to announce the immediate availability of the Jakarta POI 2.0-RC1 release. This is a release candidate for the 2.0 production release and includes a ton of bug fixes.

    The POI project consists of APIs for manipulating various file formats based upon Microsoft's OLE 2 Compound Document format using pure Java. In short, you can read and write MS Excel files using Java. Reading property information is also supported. Work continues on reading and writing the MS Word format.
    Reply to this

    Threaded Messages (14)

  2. The code looks similar[ Go to top ]

    The code looks very similar for different primitive types.
    Did they used some code generation tool ?

    Too bad J2SDK 1.5's generics do not support primitive types.

    Mileta
    Reply to this Reply to original

  3. The code looks similar[ Go to top ]

    i thought 1.5 did autoboxing which maps a primitive to objects automaticly? so you can go "5.toString()" like C#. Or was that idea killed?
    Reply to this Reply to original

  4. The code looks similar[ Go to top ]

    i thought 1.5 did autoboxing which maps a primitive to objects automaticly? so you can go "5.toString()" like C#. Or was that idea killed?


    Yes, but that way the primitive values are still held as objects under the hood. That puts presure on GC and reduces performance. Maybe some sort of dynamic class generation (as in CGLIB) could solve the problem.
    Reply to this Reply to original

  5. The code looks similar[ Go to top ]

    I do think that dynamic class generation would be a better route to go than trying to create static classes for every possible combination of primitives, and suggested as much to commons-dev at one point.
    Reply to this Reply to original

  6. Jakarta Team Releases New Jakarta Commons Primitives Package[ Go to top ]

    I found the class names to be long, confusing and humorous.

    AbstractDoubleCollectionCollection
    CollectionDoubleCollection
    IntListIteratorListIterator
    ListIteratorLongListIterator

    Cheers
    Reply to this Reply to original

  7. Naming and Design[ Go to top ]

    There was some considerable discussion as to the best design for primitives.

    Design A) (Adopted in the release)
    Primitive interfaces (eg IntCollection) are standalone. A separate wrapper class (eg IntCollectionCollection) is needed to integrate the primitive implementation with JDK Object collections. The method names can match the JDK names while returning the primitive type.

    Design B) (Not adopted)
    Primitive interfaces extends JDK Object interfaces (interface IntCollection extends Collection). No separate wrapper is needed for Object integration. However, the method names for primitive manipulation have to be modified - intIterator(), toIntArray(), getInt().

    I have done some work on design B, and am considering making it available away from Apache.

    Stephen Colebourne
    Committer - Apache Jakarta Commons
    Reply to this Reply to original

  8. Alternatives...[ Go to top ]

    After a quick glance, I think that both fastutil and PCJ are more complete alternatives...

    http://fastutil.dsi.unimi.it
    http://pcj.sourceforge.net

    Though I agree with Mileta, it's too bad 1.5's generics doesn't support primitives (aside from the convenience of boxing/unboxing).
    Reply to this Reply to original

  9. primitives[ Go to top ]

    Though I agree with Mileta, it's too bad 1.5's generics doesn't support primitives (aside from the convenience of boxing/unboxing).


    I'm working on an application that needs to keep millions of (unique) integers in memory. The app also needs to find out quickly whether a given integer exists in the collection.

    You can guess that fastutil pretty much saved the day. It uses 3..4x less memory and is a lot faster.

    +1 for primitive support in generics. It's the easiest route to less memory consuming java.
    Reply to this Reply to original

  10. Further extensions?[ Go to top ]

    Stephen,

    I read your comments regarding the design considerations A) and B) and
    understand your choice of A) - particularly in order to get the release
    out.

    How would you then solve issues such as <type>List proxies, synchronisation
    and generic passing of <type>List as a java.util.List (using the wrapper
    class I suppose)?

    I have been doing similar work in creating (some might say stupidly ground-up)
    a package of standard models (collections, lists, tables, trees etc.) that are
    'eventing' and throw modification events. The point being that these models simply extend the existing Sun Collections interfaces, with the implementation delegating to the configured sun collection, but DO NOT
    reside in the swing.* packages and are GUI independent.
    Relevant adapters to swing models are provided, of course.

    The benefits? A change to a data model, such as a list, that has been
    wired up to a JTree or JComboBox automatically updates in the GUI. Or,
    a change to a model could autotically result in the persistence
    of all/part of the model. No more messy and time-consuming hard-wiring
    in applications. Lastly, standard collections models become very
    powerful when mixed with bean models. For example, if you change a
    primitive property of a bean in an eventing list, bound to a JTable, the relevant cell of the table gets updated automatically.

    I have seen hugh gains using these models with very little performance
    impact and have been considering offering them to Jakarta or starting
    up a new beans/models project.

    Cheers,

    Gary Watson
    Co-Author Java Server Programming, J2EE 1.3 Edition, Wrox Press.
    Reviewer, Wiley.
    ___________________________________________________________________
    Reply to this Reply to original

  11. Further extensions?[ Go to top ]

    It's probably easier to use a Dynamic Proxy or AOP approach to catch all collection modifications than to create separate wrapper classes.

    Chris
    Reply to this Reply to original

  12. Further extensions?[ Go to top ]

    Chris,

    Great point, IMHO.

    I have been looking into the use of interception with AOP
    and the use of jdk 1.3 dynamic proxies. However, remember that java
    has no built-in AOP so this would require a Light Weight
    Framework (LWF) to *configure* and create the proxies and intercept changes.

    At first cut, I have opted to supply concrete implementations of eventing
    models rather than a complete framework using AOP -- people are currently
    still used to using classes directly. What's good though, is that these
    implement Sun's collections interfaces. Sun Collections (and the Jakarta Team's primitives stuff) program to interfaces, making AOP and interception possible...so hold that thought.

    As an aside, and perhaps off this thread, maybe Sun should have
    given us a comprehensive models suite (non-gui dependent) that fire
    events. Just think what problems it would have solved for us early on:
    gui wiring, interception, persistence and perhaps a better bean
    infrastructure.

    Lastly, what I'm trying to do is sir up some support for better collections
    models and bean infrastructure. Anyone who knows me, also knows I'm crazy
    about JavaBeans -- including Rod Johnson who adapted some of the beans
    stuff we worked on for the Spring framework you see today. JavaBeans based
    configuration makes Spring very powerful indeed and puts it a cut above
    the rest.

    Thanks,

    Gary
    _________________________________________________________
    Reply to this Reply to original

  13. Observable collections[ Go to top ]

    You may want to have a look at the current Commons Collections CVS. It has a new subpackage called 'observed' that contains event generating wrappers for all collection types except maps. (This is pre-release, and should be treated as such). http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/java/org/apache/commons/collections/observed/

    I would greatly value opinions on this package, or extensions to it (especially maps). I will try to monitor this forum, but commons-user at jakarta dot apache dot org mailing list may be more appropriate for fuller discussions.

    On the broader beans question, I am constantly fustrated by the Sun JavaBeans spec having never been updated. At work I have my own javabean system based on code generation that is just so useful. Gary, you might want to contact me privately.
    Reply to this Reply to original

  14. Observable collections[ Go to top ]

    Stephen,

    Thanks for the response. I took a good look at the observable collections
    stuff and it didn't take long to realise it is almost identical in nature
    (and code for that matter) to my eventing models (particularly the list)!
    Even the decorator patterns pretty much tie up.

    However, the observable events and handlers, ModificationEvent repectively, differ from mine. My implementation is a bit more lightweight and uses
    GenericEvent and GenericHandler types that mean I never need to create
    new events or handler class types (a bit lazy) for any new event - ever.

    As for the beans spec, well, perhaps I've found another who might
    be *almost* as disapointed with the lack of updates as myself #;-)
    I have a pretty good beans toolkit too, but realise it's perhaps time
    to get some feedback on it and offer it out so it can be expanded.

    Right, time to take this out of this thread. I'll be in touch, initially
    via the commons mailing list.

    Thanks,
    Gary
    __________________________________________
    Reply to this Reply to original

  15. Observable collections[ Go to top ]

    The observable stuff allows different event mechanisms, so your GenericEvent stuff could be plugged in.

    I can be contacted via http://joda.sourceforge.net , which might also interest you.
    Reply to this Reply to original