Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Java Programming Technology

What are Some Essential Java Libraries? 77

rleclerc writes "I would like to ask those 'Javaniers' in the Slashdot community what they thought were essential non-standard libraries that every Java coder should have. Normally I roll my own when it comes to that type of thing and simply build on whats available in the foundation classes. However, recent work has pushed me toward looking at some scientific libraries and I thought I would find out what libraries others in the Java community would consider an essential weapon in their Java arsenal. A few that I am looking at are the Cern scientific libraries and the Apache Commons Collections libraries. To avoid extra libraries I have opted to use the Java logging rather than the Apache one. Anyone like to add anything to the list?"
This discussion has been archived. No new comments can be posted.

What are Some Essential Java Libraries?

Comments Filter:
  • My last couple... (Score:4, Insightful)

    by (H)elix1 ( 231155 ) <slashdot.helix@nOSPaM.gmail.com> on Tuesday December 14, 2004 @07:53PM (#11087818) Homepage Journal
    The last several projects have included jakarta-regexp-1.3.jar. Yes, if you are lucky enough to be able to count on using JDK 1.4 you have another option. One jar and you are golden for regular expressions.

    The other is import org.apache.xpath.XPathAPI; My god is it nice to be able to say

    NodeList nl = XPathAPI.selectNodeList(doc, "config/adapter/config/property[@name='foo']");

    than the normal horking about with SAX or DOM parsers.
  • by Anonymous Coward on Wednesday December 15, 2004 @12:18AM (#11089825)
    The HttpUrlConnection code is broken in many ways (too many to list), so you'll need another library.

    How many other classes in the Java standard library are the same way? I'm trying to formulate a position on whether Java would've been better off to not have so many classes by default and rely on some other process to build a big armory of classes (like Perl), or if they indeed took the right path by having so many classes by default (it means companies can build on a huge amount of code that comes directly from Sun, with clear licensing terms, etc).

    For now, I tend to believe the former, but then again, I quit using Java so much after I gained a better grasp of C, which happened several years ago. Your knowledge is more current than mine, and I'd appreciate your opinion.
  • by sameb ( 532621 ) on Wednesday December 15, 2004 @01:06AM (#11090043) Homepage
    It's a tough question. Many of the built-in Java classes work wonders, and by building them in, it lets other built-in classes make use of them instead of having to build their own versions. One example is the Collections API. Sure, there could be things added/removed/changed with the API and things like ArrayList, LinkedList, HashMap, TreeSet, etc... but by including them, other necessary stuff can be simpler because they don't have to worry about a simple list or queue.

    The remaining object-oriented problem with most OO languages is that object construction is not easily object-oriented. Java's gotten around this by using service providers (for things like crypto and other places), but most SPI interfaces are bulky and difficult to use. Unless all classes use the SPI for object creation, the largest benefit is lost. A way of having 'new ArrayList()' return my ArrayList instead of Java's ArrayList would allow pre-existing classes to make use of later optimizations in different libraries.

    What I've found with many of the Java classes is that they're good for the designed scenario. HttpUrlConnection, for example, breaks if the server accepts the connection and disco's without sending any data (the connection just hangs in this instance) -- but in the vast majority of Java apps, this is never going to happen. Any robust implementation, though, needs to handle this scenario. Things like StringTokenizer are also great for simple & quick manipulation of string tokens, but are terribly inefficient.

    IMHO, Java's done an excellent job of providing an API that gets the job done 90% of the time. For that other 10%, you need external libraries.
  • by dark404 ( 714846 ) on Wednesday December 15, 2004 @01:51AM (#11090220)
    C++: As powerful as assembly, and as easy to use as... assembly.
  • by LadyLucky ( 546115 ) on Wednesday December 15, 2004 @04:32AM (#11090722) Homepage
    If it comes from apache, use it. There's so much!
    • Log4j (really, reconsider using it, it's the industry standard even with the 1.4 logging stuff, that should tell you something)
    • Tomcat for servlets, it's great
    • Velocity for a templating engine
    • Commons for your utility junk
    • Ant for building stuff
    I would also recomment as another poster has Doug Lea's concurrency utilities. If you have *anywhere* written an Object.wait() or a Object.notify[all](), then replace it with these libraries.

    Junit is indespensible and these days with the IDEs indistinguishable from the core java libraries themselves.

    Don't write SQL, use hibernate.

    For security, you cant go past the legion of the bouncy castle (I'm serious)

    Use cruise control to set up a continuous build

    And the *only* piece of closed source code we rely on is Clover coverage. It's simply fantastic. You'll love it if you adopt unit testing as your quality mechanism.

Always look over your shoulder because everyone is watching and plotting against you.

Working...