It's more for I/O, not general Object, but some methods which I almost ALWAYS 
use in a project are null-safe canonicalization and null-safe close methods.

    static File canonical(File f) {
        if (f == null) return null;
        try { return f.getCanonicalFile(); }
        catch (IOException e) { return f.getAbsoluteFile(); }
    }

    static void close(Reader s) {
        if (s == null) return;
        try { s.close(); }
        catch (IOException e) {}
    }

    static void close(Writer s) {
        if (s == null) return;
        try { s.close(); }
        catch (IOException e) {}
    }

    static void close(InputStream s) {
        if (s == null) return;
        try { s.close(); }
        catch (IOException e) {}
    }

    ... repeat for other stream types as necessary, like ZipFile, 
RandomAccessFile, etc. because no common inheritance

In some projects I've changed the above to instead have the pattern of

    static IOException close(InputStream s) {
        if (s != null) {
            try { s.close(); }
            catch (IOException e) { return e; }
        }
        return null;
    }


IMO, these are quite general in use as one should always clean up and close 
after I/O, but if the rest of it succeeded, one rarely cares if the close 
method hiccups:

    InputStream s = null;
    try {
        s = new FileInputStream(...);
        ...
    } catch (IOException e) {
        // if handling instead of throwing to caller
    } finally { close(s); }



I also think join methods would be useful for strings / collections of strings 
or similar.


Other things I often do are:

        Attempt to convert an URL to a local file, taking into account that it 
might be wrappered by jar:, that File.toURL doesn't process %20 and the like, 
etc.

        Delete files or sub-trees, catching exceptions and instead just return 
success / failure.

        Copy an InputStream to an OutputStream with supplied byte buffer (or 
allocate one internally).  General file (or stream or ?) copying utility 
methods might be useful.

        Sometimes I want strings sorted case-insensitively, but without losing 
case (or during equals comparison).


Joel



-----Original Message-----
From: core-libs-dev-boun...@openjdk.java.net 
[mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Ryan Slobojan
Sent: Friday, September 11, 2009 10:39 AM
To: core-libs-dev@openjdk.java.net
Subject: Re: What methods should go into a java.util.Objects class in JDK 7?

> Hello.
>
> For JDK 7, I think it is high-time the platform included a class like
> java.util.Objects to hold commonly-written utility methods.  For
> example, a two-argument static equals method that returned true if
> both
> arguments are null, returns false is one argument is null, and
> otherwise
> returns the result of calling arg1.equals(arg2)  (6797535 "Add shared
> two argument static equals method to the platform").
>
> A static hashCode method returning 0 for null and the value of
> arg.hashCode() has also been suggested.
>
> A set of
>
>     static int compareTo(int, int)
>     static int compareTo(long, long)
>     ....
>
> methods probably belongs somewhere in the platform too.
>
> What other utility methods would have broad enough use and
> applicability
> to go into a common java.util class?
>
> -Joe
Hi,

As a note, I've just put up an article about this on InfoQ soliciting
feedback from the wider Java community:

http://www.infoq.com/news/2009/09/jdk7-java-utils-object

Thanks,

Ryan Slobojan

Reply via email to