News: Java Gems 2009.01 Released
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.
- Posted by: Peter Varhol
- Posted on: January 27 2009 09:12 EST
- Apache Commons, anyone? by Kenny MacLeod on January 27 2009 10:53 EST
- Respect the effort, question the rationale by Jason During on January 27 2009 13:47 EST
- Generics support (was RE: Apache Commons, anyone?) by Benjamin Keil on January 27 2009 19:34 EST
- Re: Generics support (was RE: Apache Commons, anyone?) by Ignacio Coloma on January 28 2009 06:59 EST
- commons, pls by Tal Dega on February 06 2009 21:58 EST
- CLI part by Richard Richter on January 28 2009 04:43 EST
- Reinventing The weel by German Viera on January 28 2009 08:21 EST
- Re: Java Gems 2009.01 Released by Vladimir Orlov on January 28 2009 08:41 EST
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?
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?
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...
What would be my motivation to use your framework over a (generally) industry accepted framework with a large user community like Apache Commons?
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.
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.
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".
+1 for google collections over commons collections (generics support, much more respect for jdk interface contracts, smarter api).
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.
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. :-)
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?
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?
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.