Java Gems 2009.01 Released

Home

News: Java Gems 2009.01 Released

  1. Java Gems 2009.01 Released (11 messages)

    Exactly two months after the previous release, a new version of Java Gems general-purpose library was released. In the very short history of this project, this release is the closest to the original goal to provide small tools, which are re-implemented again and again in many projects, only because they are too simple for their own library. The main project page is http://code.google.com/p/javagems/ . Besides new features and improvements listed in release notes, we also significantly increased test coverage behind the scene. Measured by Emma, the Java Gems library has 68% of classes and 65% of lines covered by unit tests now. See the complete release notes (http://code.google.com/p/javagems/wiki/ReleaseNotes2009_01) for more information.

    Threaded Messages (11)

  2. Apache Commons, anyone?[ Go to top ]

    From your page, the functionality provided is * Filtering. General purpose filtering interface, with null implementation and and, or and not operations for putting filters together. Already part of Commons Collections, if I'm reading this right. * Command Line arguments parsing. CLI library implementation separating options as designed from options as typed. Commons CLI * Logging library. Commons Logging Please tell me you're not just going about re-implementing Apache Commons from scratch?
  3. Couldn't agree more. I would be interested to hear the rationale behind the development of this framework. Most developers will extend or develop something on their own because: a) Something doesn't already exist b) What does exist is either impractical, difficult to use, cumbersome, insufficient etc. What would be my motivation to use your framework over a (generally) industry accepted framework with a large user community like Apache Commons?


  4. What would be my motivation to use your framework over a (generally) industry accepted framework with a large user community like Apache Commons?
    well, for one there is much less code than in commons :-) and the javadoc is good. Sorry for bashing, but honestly, I'd feel embarassed posting this kind of release notice (and repeat it every couple of months) to TSS. There is almost no code in "javagems", which provides next to no value, not to mention added value with respect to, say log4j, or commons-cli, or commons-collections. The editor is out for lunch, it seems, or too busy banning turkish spam posters...
  5. Filtering. General purpose filtering interface, with null implementation and and, or and not operations for putting filters together.
    Already part of Commons Collections, if I'm reading this right.
    One issue here is that these filters support generics while those in Commons do not. I like the Jakarta Commons a lot---I use their pools, and their codecs, and lots of other things---, but I have rolled my own filters and collections utilities because Commons Collections will not implement generics support.
  6. Google-collections supports generics and is an amazingly good implementation. I find ironic these posts about "not having to reimplement again something that already exists".
  7. Google collections[ Go to top ]

    +1 for google collections over commons collections (generics support, much more respect for jdk interface contracts, smarter api).
  8. commons, pls[ Go to top ]

    Commons should not be extended. It would be a really bad idea. The fact that commons wont implement generic collections is all you need to know. This library is a dinosaur. There is definitely a role for ANYONE who wants to try and do better, and they should reject commons. If commons was so great this stuff wouldnt exist. What about the in house roll your own thats better than commons but not important enough for apache to care? Commons is all you need if you dont care about reuse.
  9. CLI part[ Go to top ]

    From what I remember using Commons CLI it was quite a strange code and also we were not satisfied with its command line parsing results. From what I've seen Gems this part seems to be nicer. Filtering with generics is nice too, I'm not a friend of another Logging though - especially when I can't find configuration which is very important part of that. I know the author and if I go for some CLI, I'll try this one. Commons is great effort and I use it ... mostly as a dependency to something else. :-) But some things in Commons drive me nuts. Commons Net didn't work properly for Solaris FTP between 1.2 and 1.5, there is JDK 1.4 (or older) compatibility that can sometimes limit the way you can do things in Java 5 and newer, etc... If Gems are small as they are, I'll use them for CLI alone (or Filters) ignoring Logging and Shower easter egg. :-)
  10. Reinventing The weel[ Go to top ]

    Reinventing the weel....this comment says all. It would be nicer to see Java Gems effort to complement other libraries as Apache Commons. Why a completely new library?
  11. Re: Java Gems 2009.01 Released[ Go to top ]

    It may have the same idea in general behind as Apache Commons have. In such a case they both are going to be competitive solutions for the same problem and I don't see anything bad in that. Did anybody loose cause of different open source Java IDEs (like Eclipse and NetBeans) existence?
  12. The more the better[ Go to top ]

    I second the opinion that competing solutions are good. Who are we to deride and then demand that someone’s effort be spent one way or the other? Are you the same type that demands the government force me do this thing or the other just because you think so? Guys, go ahead and build your gems. Spend your effort as you find fit. I bet these naysayers have never contributed to anything in their spare time.