Initial version of the Java Gems project

Home

News: Initial version of the Java Gems project

  1. Initial version of the Java Gems project (18 messages)

    Java Gems are simple code snippets copied again and again from one project to another, often from your private project to several work projects, those small things you cannot find in java.util and its subpackages. The main goal is to provide Java developers a way how to share tools and utilities without a necessity to reinvent them in each project or when moving to another team or changing a job. Today it includes: Filtering. General purpose filtering interface, with null implementation and and, or and not operations for putting filters together. Command Line arguments parsing. CLI library implementation separating options as designed from options as typed. Find out more at http://code.google.com/p/javagems/

    Threaded Messages (18)

  2. How is this different from Jakarta commons?
  3. Instead of posting "stupid" questions just look at source code and post your review which will compare this project with jakarta commons. Maybe then this site will be much fun to read as it was back in 2001.
  4. There's no need of being rude. Besides, you can apply your "advice" to yourself. Instead of insulting readers; make the review yourself and post it.
  5. Instead of posting "stupid" questions just look at source code and post your review which will compare this project with jakarta commons. Maybe then this site will be much fun to read as it was back in 2001.
    What a pair you two are! One doesn't RTFA and the other spews insults. Perhaps you should both try www.slashdot.org. You might fit in better.
  6. I thought I should not dignify your review by a reply, but here it goes. Yes, I did read the FAQ and the motivation before posting the question. In concept, I really don't see it to be any different than existing reuse APIs. I don't see how the dependency headaches can be avoided if Java Gems becomes popular itself. Suppose hibernate is using JavaGems 1.0 and I plan to use 2.0. I'm screwed anyways right? (Unless I plan to use other ways of managing dependencies) Instead of creating a million different frameworks to do the same damn thing, we should try to consolidate effort into a few good choices. For the inquisitive, I would recommend Paradox of Choice If you want to get excited about every new shiny toy.. Go for it.
  7. RTMF[ Go to top ]

    Or, even better, read the FAQ just two clicks away: http://code.google.com/p/javagems/wiki/FAQs :p
  8. Pardon frickin me...[ Go to top ]

    A bit of a harsh response I'd say. That wiki entry looks like it was only written today - possibly following the question re Jakarta Commons.
  9. I've got to play devil's advocate here and ask what, to me, is the obvious question: how is this different than any of the other projects out there like this? What makes it better? Why should I use it, and maybe more importantly, contribute to it? Also, am I missing something or is there really only two pieces of functionality in it right now? Seems a little... minimal... for an initial announcement. Maybe I missed some stuff somewhere?
  10. new project name[ Go to top ]

    When I think of "Gems", I think of any code snippet found on: http://thedailywtf.com
  11. Re: new project name[ Go to top ]

    Not quite going that far, but I agree with the "snippet" part. I was hoping to see, basically a bunch of code "gems" that don't need to be downloaded, per se, but rather, simply cut and pasted in to your project. Rather than downloading some class library, you can just go ala carte and easily pick what you want. No, or very few dependencies, < 30 lines of code, and you can just use the code outright. Heck, not even classes, just methods. Things like that.
  12. Cut and paste[ Go to top ]

    If you want some collaborative cut and paste try this : http://gist.github.com/gists
  13. I don't really have a strong feeling about this project in particular. As pointed out it above, it's a little thin but I think the idea is to get contributions at this point. I have a larger question about the usefulness of packages like this. I'm ambivalent about Jakarta Commons in particular. Most of the time I've seen it used, the pain of managing the dependency is more work than the 10 or so lines of trivial code it eliminated. There's a lot there and surely a lot of it is useful but it seems like part of a trend of creating open source projects just to create open source projects without solving any real problems. Does anyone on this thread find Jakarta Commons or a similar package to be an important part of their development stack?
  14. @James: I feel that Commons FileUpload is irreplaceable. Isn't that the case?
  15. @James: I feel that Commons FileUpload is irreplaceable. Isn't that the case?
    Sorry, I need to be more specific. Looking at the commons set there are definitely things that are very useful. I guess I'm talking more about things like the Jakarta Lang package which are similar to the Java Gems project in scope.
  16. I guess I'm talking more about things like the Jakarta Lang package which are similar to the Java Gems project in scope.
    Yes you are right. Lang seems useful but most of the time I use 0.1% of it. For example I now use it just for its ClassUtils.getShortClassName(). And being a 256kb jar, it makes perfect sense to copy/paste this method inside my codebase.
  17. For example I now use it just for its ClassUtils.getShortClassName().
    If that's the only reason, just use java.lang.Class#getSimpleName() and get rid of that dependency completely.
  18. Thats true. But getShortClassName() is available since 1.5. Probably the project mentioned is based on 1.4?
  19. Take a look at "Application Factories" in the new version of JBuilder? IMHO this is more powerful way for reuse of Java code.